Skip to content

Cloud Computing & DevOps ​

Engineer Resilient Linux Servers, Containerised Microservices, Multi-Cloud Infrastructure (AWS & Azure), Automated CI/CD Pipelines, and Terraform IaC

12Weeks
5Stages
60+Lessons
8Projects
CLI/Web BasicsPrerequisites

Welcome to the Tech Minds Academy Cloud Computing & DevOps Track. Modern software has zero value sitting on a laptop—it only creates impact when deployed reliably, securely, and cost-effectively in production. Across 12 intensive, lab-driven weeks at our Bwari, Abuja campus (G5 Plaza, Sabon-Gari Road) or Live Online, you will progress from bare-metal Linux administration and networking fundamentals to containerising full-stack applications with Docker, provisioning cloud infrastructure across Amazon Web Services (AWS) and Microsoft Azure, automating zero-downtime releases with GitHub Actions, codifying cloud architecture with Terraform, and instrumenting production observability with Prometheus and Grafana.

TIP

Before Week 1, complete the Developer Environment Setup Guide (specifically WSL2 Ubuntu on Windows or macOS/Linux terminal tools) and review the Git & GitHub Workflow Guide. Learners new to web backends can also pair or precede this track with Node.js & Backend Development.


Programme Overview ​

AttributeDetails
Track TitleCloud Computing, DevOps & Infrastructure Engineering
Duration12 Weeks (5 Progressive Stages · 72 Guided Lab Lessons)
Delivery ModesIn-Person Cohort (Bwari, Abuja) & Instructor-Led Live Online
Weekly Commitment6–8 Hours Instructor Labs + 6–8 Hours Self-Paced Cloud Architecture Practice
PrerequisitesComfort with file systems, basic command-line navigation, Git basics, and understanding how web apps work
Cloud PlatformsAmazon Web Services (AWS Free Tier / Sandbox) & Microsoft Azure
Core StackUbuntu Linux, Bash, Nginx, Docker, Docker Compose, GitHub Actions, Terraform (HCL), Prometheus, Grafana
Portfolio Output8 Production-Grade Infrastructure Repositories + Week 12 Automated Cloud Capstone
Certification PathwaysPrepares learners for AWS Certified Solutions Architect – Associate (SAA-C03), Azure Fundamentals (AZ-900 / AZ-104), and HashiCorp Terraform Associate

Curriculum Rationale ​

1. Why Linux & Networking First? ​

Over 90% of public cloud workloads, containers, and CI/CD runners execute on Linux kernels, and the majority of production outages stem from DNS misconfigurations, CIDR routing errors, firewall rules, or TLS certificate issues. Clicking buttons in a cloud console without understanding Linux processes, systemd, permissions, TCP/IP, subnets, and reverse proxies turns troubleshooting into guesswork. Stage 1 builds unshakeable systems and networking intuition first.

2. Why Multi-Cloud (AWS + Microsoft Azure)? ​

In Nigeria, West Africa, and global remote engineering teams, startups and fintechs predominantly run on AWS, while banks, telecoms, government agencies, and enterprise consultancies standardize heavily on Microsoft Azure (paired with Microsoft Entra ID and M365). Mastering AWS deeply while learning how every core primitive maps to Azure makes you immediately employable across both ecosystems—and teaches you portable cloud architecture rather than vendor memorisation.

3. Why Infrastructure as Code (IaC) & FinOps? ​

Manual "ClickOps" infrastructure cannot be code-reviewed, versioned, audited, or cleanly torn down—leading to configuration drift and surprise cloud bills. From Stage 3 onward, we instil Cloud FinOps (budget alarms, right-sizing, teardown discipline), and in Stage 4 you replace manual console provisioning with repeatable Terraform HCL modules and GitHub Actions pipelines.


Stage 1: Linux Systems, Bash Scripting & Cloud Networking (Weeks 1–2) ​

Goal: Operate headless Ubuntu Linux servers confidently via SSH, automate administrative workflows in Bash, design IPv4 CIDR networks, and serve web workloads securely behind Nginx.

Week 1: Linux Administration, Permissions & Bash Automation ​

LessonTopicCore Engineering Concepts
1.1The Linux Kernel, Boot Lifecycle & Filesystem HierarchyKernel vs user space, /etc, /var/log, /opt, /proc, /home, inodes, symlinks vs hard links
1.2Users, Groups, sudo & Octal/Symbolic PermissionsPrinciple of least privilege, /etc/passwd, chmod, chown, umask, SUID/SGID awareness
1.3Package Management, Processes & systemd Servicesapt, ps aux, htop, signals (SIGTERM vs SIGKILL), writing custom .service unit files, journalctl
1.4Secure Remote Access with OpenSSHEd25519 keypair generation, ~/.ssh/authorized_keys, ~/.ssh/config, scp/rsync, disabling root password login
1.5Text Processing, Streams & Pipingstdin/stdout/stderr, redirection, grep, awk, sed, jq for JSON API/CLI output parsing
1.6Defensive Bash Scripting & cron Schedulingset -euo pipefail, variables, exit codes, conditionals, loops, log rotation, crontab & systemd timers

Weekly Project 1 — Automated Linux Server Bootstrap & Health Audit Script: Provision a fresh Ubuntu 24.04 LTS virtual machine, harden SSH access, deploy a custom systemd background service, and write an idempotent Bash script (bootstrap-and-audit.sh) scheduled via cron to monitor disk, memory, failed SSH logins, and service uptime.

Practical Example: Defensive Bash Health & Backup Script ​

bash
#!/usr/bin/env bash
# Tech Minds Cloud Track — Production-Safe Server Audit & Backup Script
set -euo pipefail
IFS=$'\n\t'

readonly LOG_FILE="/var/log/techminds-health.log"
readonly BACKUP_DIR="/var/backups/app-configs"
readonly DISK_THRESHOLD=80
readonly TIMESTAMP="$(date -u +"%Y-%m-%dT%H:%M:%SZ")"

log() {
  local level="$1"
  local message="$2"
  printf '[%s] [%s] %s\n' "$TIMESTAMP" "$level" "$message" | tee -a "$LOG_FILE"
}

check_service() {
  local svc="$1"
  if systemctl is-active --quiet "$svc"; then
    log "INFO" "Service '${svc}' is active and running."
  else
    log "ERROR" "Service '${svc}' is DOWN. Attempting restart..."
    systemctl restart "$svc"
    systemctl is-active --quiet "$svc" && log "INFO" "Service '${svc}' recovered."
  fi
}

check_disk_usage() {
  local usage
  usage="$(df -P / | awk 'NR==2 {gsub("%","",$5); print $5}')"
  if (( usage >= DISK_THRESHOLD )); then
    log "WARN" "Root filesystem usage is ${usage}% (threshold: ${DISK_THRESHOLD}%)."
  else
    log "INFO" "Root filesystem usage healthy at ${usage}%."
  fi
}

backup_nginx_configs() {
  mkdir -p "$BACKUP_DIR"
  local archive="${BACKUP_DIR}/nginx-etc-${TIMESTAMP//:/-}.tar.gz"
  tar -czf "$archive" -C /etc nginx
  # Retain only the 7 most recent archives
  ls -1t "${BACKUP_DIR}"/nginx-etc-*.tar.gz | tail -n +8 | xargs -r rm -f
  log "INFO" "Created configuration backup: ${archive}"
}

main() {
  check_disk_usage
  check_service "nginx"
  check_service "ssh"
  backup_nginx_configs
}

main "$@"

Week 2: Cloud Networking, DNS, TLS & Nginx Reverse Proxies ​

LessonTopicCore Engineering Concepts
2.1OSI vs TCP/IP Models & Packet FlowL3 routing vs L4 TCP/UDP ports vs L7 HTTP/HTTPS, 3-way handshake, ephemeral ports, MTU
2.2IPv4 Addressing, CIDR Notation & SubnettingCalculating subnet masks (/16, /24, /28), private RFC 1918 ranges, gateway & broadcast addresses
2.3DNS Resolution Hierarchy & Record TypesRoot/TLD/Authoritative nameservers, A, AAAA, CNAME, TXT, MX, NS, TTL caching, dig & nslookup
2.4HTTP/1.1, HTTP/2, TLS Handshakes & Let's EncryptTLS certificates, SANs, Certbot ACME challenges, HSTS, debugging endpoints with curl -v and openssl s_client
2.5Host Firewalls & Network Diagnosticsufw, iptables/nftables basics, ss -tulpn, traceroute, mtr, nc (netcat) port reachability checks
2.6Nginx as Web Server, Reverse Proxy & Load BalancerVirtual hosts (server blocks), proxy_pass, upstream pools, health checks, rate limiting, gzip/Brotli

Weekly Project 2 — TLS-Terminated Nginx Reverse Proxy & Load-Balanced Upstream: Configure a Linux host running two local Node.js/Python application instances on private loopback ports (127.0.0.1:4001 and 127.0.0.1:4002), lock down external ports with ufw (22, 80, 443 only), and place Nginx in front with upstream round-robin load balancing, security headers, rate limiting, and automated Let's Encrypt HTTPS.


Stage 2: Containerisation with Docker (Weeks 3–4) ​

Goal: Eliminate "it works on my machine" failures by packaging applications into minimal, non-root, multi-stage OCI images and orchestrating multi-service stacks with Docker Compose.

Week 3: Container Internals, Image Engineering & Security ​

LessonTopicCore Engineering Concepts
3.1Virtual Machines vs ContainersLinux namespaces (pid, net, mnt, user), cgroups resource limits, OverlayFS union filesystem layers
3.2Docker CLI Lifecycle & Debuggingdocker run, exec, logs, inspect, stats, port publishing (-p), environment injection, exit code forensics
3.3Writing Clean Dockerfiles & Layer CachingInstruction ordering for deterministic build cache hits, COPY vs ADD, .dockerignore hygiene, ENTRYPOINT vs CMD
3.4Multi-Stage Builds & Minimal Base ImagesSeparating build toolchains from runtime images, alpine vs slim vs distroless, shrinking 1.1 GB images to < 120 MB
3.5Container Security HardeningRunning as non-root USER, read-only root filesystems, dropping Linux capabilities, scanning CVEs with docker scout / Trivy
3.6Tagging Semantic Releases & Registry WorkflowsImage digests (sha256), immutable version tags vs latest pitfalls, pushing to Docker Hub & GitHub Container Registry (GHCR)

Weekly Project 3 — Hardened Multi-Stage Dockerfile Optimization Challenge: Take an unoptimised TypeScript/Node.js API image weighing 1.15 GB running as root and refactor it into a multi-stage Dockerfile under 130 MB, running as an unprivileged user with built-in container HEALTHCHECK and zero critical vulnerabilities in Trivy.

Practical Example: Production Multi-Stage Dockerfile ​

dockerfile
# syntax=docker/dockerfile:1.7

# ─── Stage 1: Dependency Installation ────────────────────────────────────────
FROM node:22-bookworm-slim AS deps
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci

# ─── Stage 2: TypeScript Compilation ─────────────────────────────────────────
FROM deps AS builder
WORKDIR /app
COPY tsconfig.json ./
COPY src ./src
RUN npm run build && npm prune --omit=dev

# ─── Stage 3: Minimal Hardened Production Runtime ────────────────────────────
FROM node:22-bookworm-slim AS runner
WORKDIR /app

ENV NODE_ENV=production \
    PORT=3000

# Create dedicated non-root system user and group
RUN groupadd --system --gid 1001 appgroup \
 && useradd --system --uid 1001 --gid appgroup --no-create-home appuser

COPY --from=builder --chown=appuser:appgroup /app/node_modules ./node_modules
COPY --from=builder --chown=appuser:appgroup /app/dist ./dist
COPY --from=builder --chown=appuser:appgroup /app/package.json ./package.json

USER appuser
EXPOSE 3000

HEALTHCHECK --interval=30s --timeout=5s --start-period=15s --retries=3 \
  CMD node -e "fetch('http://127.0.0.1:3000/healthz').then(r => process.exit(r.ok ? 0 : 1)).catch(() => process.exit(1))"

CMD ["node", "dist/server.js"]

Week 4: Persistent Storage, Bridge Networks & Docker Compose Stacks ​

LessonTopicCore Engineering Concepts
4.1Stateful Data in Ephemeral ContainersNamed volumes vs bind mounts vs tmpfs, database storage paths, backup/restore of Docker volumes
4.2Docker Networking Drivers & Service DiscoveryDefault bridge vs user-defined bridge networks, embedded DNS service name resolution, internal-only backend networks
4.3Multi-Container Orchestration with Docker Composecompose.yaml specification, depends_on with condition: service_healthy, restart: unless-stopped
4.4Secrets, Environment Files & Profiles.env.example patterns, Docker Compose secrets, separating dev vs prod Compose overrides and profiles
4.5Local Reverse Proxy, Caching & Database TopologiesWiring Nginx + API + PostgreSQL 16 + Redis 7 so PostgreSQL and Redis are completely isolated from host ports
4.6Resource Quotas, Log Drivers & Zero-Leak CleanupMemory/CPU reservations, json-file log rotation (max-size, max-file), pruning dangling layers safely

Weekly Project 4 — Full-Stack 4-Service Production Compose Architecture: Architect and document a reproducible multi-container stack (Nginx Reverse Proxy + REST API + PostgreSQL + Redis) separated across frontend_net and backend_net internal networks, complete with health-gated startup ordering, persistent database volumes, and automated pg_dump backup scripts.

Practical Example: Multi-Network docker-compose.yml Stack ​

yaml
name: techminds-commerce-stack

services:
  proxy:
    image: nginx:1.27-alpine
    restart: unless-stopped
    ports:
      - "80:80"
    volumes:
      - ./infra/nginx/default.conf:/etc/nginx/conf.d/default.conf:ro
    depends_on:
      api:
        condition: service_healthy
    networks:
      - edge_net

  api:
    build:
      context: .
      dockerfile: Dockerfile
    restart: unless-stopped
    environment:
      NODE_ENV: production
      PORT: 3000
      DATABASE_URL: postgresql://${POSTGRES_USER}:${POSTGRES_PASSWORD}@postgres:5432/${POSTGRES_DB}
      REDIS_URL: redis://redis:6379
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_healthy
    networks:
      - edge_net
      - data_net
    deploy:
      resources:
        limits:
          cpus: "1.0"
          memory: 512M

  postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: ${POSTGRES_DB}
    volumes:
      - pg_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
      interval: 10s
      timeout: 5s
      retries: 5
    networks:
      - data_net

  redis:
    image: redis:7.4-alpine
    restart: unless-stopped
    command: ["redis-server", "--appendonly", "yes"]
    volumes:
      - redis_data:/data
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      timeout: 3s
      retries: 5
    networks:
      - data_net

networks:
  edge_net:
    driver: bridge
  data_net:
    driver: bridge
    internal: true

volumes:
  pg_data:
  redis_data:

Stage 3: AWS & Microsoft Azure Core Infrastructure (Weeks 5–7) ​

Goal: Design secure, fault-tolerant cloud architectures across AWS and Microsoft Azure with strict IAM least privilege, private networking, managed databases, serverless functions, and FinOps cost guardrails.

Week 5: AWS Identity, VPC Networking & Compute (IAM, VPC, EC2, ALB) ​

LessonTopicCore Engineering Concepts
5.1AWS Global Infrastructure & Shared ResponsibilityRegions, Availability Zones (AZs), Edge Locations, Root account lockdown, MFA, AWS Budgets billing alerts
5.2AWS IAM Deep Dive & Least PrivilegeIAM Users vs Roles vs Policies, JSON policy evaluation logic, temporary STS credentials, IAM Instance Profiles
5.3Custom VPC Architecture from ScratchPublic vs Private subnets across 2 AZs, Internet Gateway (IGW), NAT Gateway / NAT Instance tradeoffs, Route Tables
5.4Stateful vs Stateless Network BoundariesSecurity Groups (stateful instance/service firewalls) vs Network ACLs (stateless subnet boundaries)
5.5EC2 Compute, AMIs, EBS Storage & SSMInstance families (t3, c7g Graviton), EBS gp3 volumes & snapshots, User Data bootstrapping, AWS Systems Manager Session Manager (keyless SSH)
5.6Application Load Balancers (ALB) & Auto ScalingTarget groups, L7 path routing, ACM TLS certificates, Auto Scaling Groups (ASG) scaling policies

Weekly Lab Milestone (Week 5) — Custom 2-AZ AWS VPC, Bastion-less SSM Access & ALB Target Group: Architect and verify a custom AWS VPC spanning two Availability Zones with public/private route tables, Security Groups, keyless Systems Manager (SSM) EC2 access, and an Application Load Balancer routing HTTP/HTTPS traffic—forming the network foundation for Project 5 in Week 6.


Week 6: AWS Storage, Managed Databases & Serverless (S3, CloudFront, RDS, Lambda) ​

LessonTopicCore Engineering Concepts
6.1Amazon S3 Durability, Security & Lifecycle PoliciesBucket policies, Block Public Access, SSE-S3 / SSE-KMS encryption, versioning, Intelligent-Tiering & Glacier rules, presigned URLs
6.2Global Edge Delivery with CloudFront & Route 53Origin Access Control (OAC) for private S3 buckets, cache invalidations, Route 53 alias records & health-checked failover
6.3Managed Relational Databases with Amazon RDSProvisioning PostgreSQL in private DB subnets, Multi-AZ high availability, automated backups, parameter groups, Secrets Manager
6.4Container Hosting on AWS (ECR, ECS Fargate & App Runner)Pushing images to Amazon ECR, task definitions, serverless container execution on AWS Fargate vs EC2 launch types
6.5Event-Driven Serverless with AWS Lambda & API GatewayCold starts, execution roles, S3/SQS event triggers, HTTP API Gateway integration, idempotent serverless handlers
6.6AWS Well-Architected Pillars & CLI AutomationAutomating cloud inspection with aws CLI v2, tagging strategies (Environment, Owner, CostCenter), CloudTrail audit logs

Weekly Project 5 — Multi-AZ AWS Web & Managed RDS Architecture: Deploy a fault-tolerant web application inside a custom 2-AZ AWS VPC: static frontend served globally via CloudFront + private S3 (OAC), containerised API behind an Application Load Balancer, Amazon RDS PostgreSQL isolated in private subnets, and an AWS Lambda worker processing S3 uploads—all governed by least-privilege IAM roles and a $5 AWS Budget alarm.


Week 7: Microsoft Azure Core Infrastructure & Multi-Cloud FinOps ​

LessonTopicCore Engineering Concepts
7.1Azure Hierarchy & Microsoft Entra ID (formerly Azure AD)Tenant → Management Groups → Subscriptions → Resource Groups, Role-Based Access Control (RBAC), Managed Identities
7.2Azure Virtual Networks (VNet) & Network SecuritySubnets, Network Security Groups (NSGs), Application Security Groups, Azure Bastion, AWS-to-Azure architecture mapping
7.3Azure Compute: Virtual Machines, App Service & Container AppsLinux VMs, Azure App Service deployment slots (staging → production swap), Azure Container Apps (ACA)
7.4Azure Blob Storage & Managed PostgreSQL Flexible ServerStorage accounts, hot/cool/archive tiers, SAS tokens, Azure Database for PostgreSQL with private VNet integration
7.5Azure CLI (az) & ARM/Bicep Conceptual MappingManaging Resource Groups via az CLI, resource locks (CanNotDelete), clean environment teardown (az group delete)
7.6Cloud Cost Engineering (FinOps) for African & Global TeamsRight-sizing compute, Spot/Savings Plans, NAT Gateway & egress cost traps, Azure Cost Management + AWS Cost Explorer

Weekly Project 6 — Azure Containerised App Service + FinOps Cost Comparison Report: Deploy your containerised API and managed PostgreSQL database into a dedicated Azure Resource Group using Azure Container Apps / App Service, Blob Storage, and Managed Identity authentication—accompanied by a side-by-side AWS vs Azure monthly FinOps bill breakdown for a 10,000-user Nigerian SaaS workload.


Stage 4: CI/CD Pipelines & Infrastructure as Code with Terraform (Weeks 8–10) ​

Goal: Replace manual deployments and console clicking with automated GitHub Actions delivery pipelines and modular, state-managed Terraform HCL infrastructure.

Week 8: Continuous Integration & Security Gates with GitHub Actions ​

LessonTopicCore Engineering Concepts
8.1CI/CD Engineering Principles & Trunk-Based FlowsFast feedback loops, branch protection rules, semantic PR checks, artifact immutability ("build once, promote everywhere")
8.2GitHub Actions ArchitectureWorkflows, triggers (push, pull_request, workflow_dispatch), jobs, runners, matrix strategies, dependency caching
8.3Automated Quality Gates: Lint, Typecheck & Integration TestsService containers in GitHub Actions (ephemeral Postgres/Redis for CI test suites), failing fast on regressions
8.4DevSecOps in CI: Secret Scanning, SAST & Trivy Image ScansPreventing leaked API keys (gitleaks), npm audit, scanning built Docker images before registry push
8.5Keyless Cloud Authentication via OpenID Connect (OIDC)Eliminating long-lived AWS_SECRET_ACCESS_KEY secrets in GitHub by federating GitHub OIDC directly with AWS IAM & Azure Entra
8.6Building & Publishing Multi-Arch Images to GHCR / Amazon ECRDocker Buildx cache backends (type=gha), tagging images with Git commit SHAs and semantic tags

Weekly Project 6B / Lab Milestone (Week 8) — Keyless OIDC GitHub Actions CI + Trivy Gate Pipeline: Build an automated GitHub Actions pipeline with ephemeral PostgreSQL test containers, Trivy CVE blocking gates, and keyless AWS OIDC image pushes to Amazon ECR / GHCR on every merge to main.

Practical Example: GitHub Actions CI/CD Pipeline with OIDC & Trivy Gate ​

yaml
name: CI/CD — Test, Scan, Push ECR & Deploy

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

permissions:
  id-token: write   # Required for keyless AWS OIDC federation
  contents: read
  security-events: write

env:
  AWS_REGION: eu-west-1
  ECR_REPOSITORY: techminds-api

jobs:
  test:
    name: Lint, Typecheck & Integration Tests
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:16-alpine
        env:
          POSTGRES_USER: testuser
          POSTGRES_PASSWORD: testpassword
          POSTGRES_DB: testdb
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5
        ports:
          - 5432:5432
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm test
        env:
          DATABASE_URL: postgresql://testuser:testpassword@localhost:5432/testdb

  build-scan-deploy:
    name: Build Image, Scan CVEs & Deploy to ECS
    needs: test
    if: github.event_name == 'push' && github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Configure AWS Credentials via Keyless OIDC
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_GH_OIDC_ROLE_ARN }}
          aws-region: ${{ env.AWS_REGION }}

      - name: Login to Amazon ECR
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v2

      - name: Build Docker Image Tagged with Commit SHA
        env:
          REGISTRY: ${{ steps.login-ecr.outputs.registry }}
          IMAGE_TAG: ${{ github.sha }}
        run: |
          docker build -t "$REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG" .

      - name: Run Trivy Vulnerability Gate (Block Critical/High CVEs)
        uses: aquasecurity/trivy-action@0.28.0
        with:
          image-ref: ${{ steps.login-ecr.outputs.registry }}/${{ env.ECR_REPOSITORY }}:${{ github.sha }}
          format: table
          exit-code: "1"
          ignore-unfixed: true
          severity: CRITICAL,HIGH

      - name: Push Verified Image to ECR & Roll Out Service
        env:
          REGISTRY: ${{ steps.login-ecr.outputs.registry }}
          IMAGE_TAG: ${{ github.sha }}
        run: |
          docker push "$REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG"
          aws ecs update-service \
            --cluster techminds-prod-cluster \
            --service techminds-api-svc \
            --force-new-deployment

Week 9: Terraform Fundamentals & Remote State Architecture ​

LessonTopicCore Engineering Concepts
9.1Declarative IaC & The Terraform Core Workflowterraform init, fmt, validate, plan, apply, destroy, provider plugin pinning
9.2HCL Syntax: Resources, Data Sources, Variables & Outputsvariable validation blocks, .tfvars, locals, sensitive outputs, implicit vs explicit dependency graphs
9.3Terraform State Internals & Remote Backend LockingWhy terraform.tfstate must never be committed to Git; configuring encrypted S3 remote state + locking
9.4Dynamic Expressions: count, for_each & Lifecycle RulesProvisioning multi-AZ subnets cleanly with for_each, create_before_destroy, prevent_destroy on stateful DBs
9.5Importing Brownfield Cloud Resources & Drift Detectionterraform import blocks, reconciling manual console changes, running terraform plan -detailed-exitcode
9.6Provisioning AWS VPC, Security Groups & ECR in HCLTranslating Stage 3's manual network & registry architecture into clean, formatted Terraform code

Weekly Lab Milestone (Week 9) — Encrypted S3 Remote State & Terraform VPC Baseline: Bootstrap an encrypted S3 remote state backend with lockfile protection and codify your 2-AZ VPC, subnets, Security Groups, and ECR repository in validated Terraform HCL (Part 1 of Project 7).


Week 10: Reusable Terraform Modules & Zero-Downtime Continuous Deployment ​

LessonTopicCore Engineering Concepts
10.1Designing Composable Terraform ModulesRoot vs child modules (modules/vpc, modules/ecs-service), clean input/output contracts, semantic versioning
10.2Multi-Environment Topologies (staging vs prod)Directory-based isolation (envs/staging, envs/prod) vs workspaces, parity with cost-scaled instance sizes
10.3Automating Terraform in GitHub Actions PR WorkflowsPosting terraform plan diffs on Pull Requests, protected GitHub production Environment approval gates before apply
10.4IaC Security & Policy ScanningStatic security scanning of Terraform HCL with tfsec / Trivy Config / Checkov before resources touch the cloud
10.5Zero-Downtime Deployment StrategiesRolling updates, Blue/Green target group swaps, Canary traffic shifting, database migration safety (expand-and-contract)
10.6Automated Rollbacks & Smoke TestingPost-deploy synthetic health checks in CI/CD, automatic rollback alarms on elevated 5xx error rates

Weekly Project 7 — Modular Terraform Cloud Foundation + Automated GitOps Pipeline: Author reusable Terraform modules (vpc, rds, ecs_app) with remote encrypted S3 state, staging and prod environment configurations, automated terraform plan PR previews, Trivy IaC security checks, and zero-downtime rolling container deployments triggered on merge to main.

Practical Example: Production-Grade Terraform HCL (main.tf) ​

hcl
terraform {
  required_version = ">= 1.9.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.70"
    }
  }

  backend "s3" {
    bucket       = "techminds-tfstate-prod-eu-west-1"
    key          = "envs/prod/terraform.tfstate"
    region       = "eu-west-1"
    encrypt      = true
    use_lockfile = true
  }
}

provider "aws" {
  region = var.aws_region

  default_tags {
    tags = {
      Project     = var.project_name
      Environment = var.environment
      ManagedBy   = "Terraform"
      Academy     = "Tech Minds"
    }
  }
}

locals {
  azs = ["${var.aws_region}a", "${var.aws_region}b"]
}

resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr
  enable_dns_support   = true
  enable_dns_hostnames = true

  tags = {
    Name = "${var.project_name}-${var.environment}-vpc"
  }
}

resource "aws_subnet" "public" {
  for_each = { for idx, az in local.azs : az => cidrsubnet(var.vpc_cidr, 8, idx) }

  vpc_id                  = aws_vpc.main.id
  availability_zone       = each.key
  cidr_block              = each.value
  map_public_ip_on_launch = true

  tags = {
    Name = "${var.project_name}-${var.environment}-public-${each.key}"
    Tier = "public"
  }
}

resource "aws_subnet" "private" {
  for_each = { for idx, az in local.azs : az => cidrsubnet(var.vpc_cidr, 8, idx + 10) }

  vpc_id            = aws_vpc.main.id
  availability_zone = each.key
  cidr_block        = each.value

  tags = {
    Name = "${var.project_name}-${var.environment}-private-${each.key}"
    Tier = "private"
  }
}

resource "aws_ecr_repository" "app" {
  name                 = "${var.project_name}-${var.environment}-api"
  image_tag_mutability = "IMMUTABLE"

  image_scanning_configuration {
    scan_on_push = true
  }
}

Stage 5: Observability, Reliability & Cloud Capstone (Weeks 11–12) ​

Goal: Gain real-time visibility into system behaviour with structured telemetry, Prometheus metrics, Grafana dashboards, actionable alerting, and blameless SRE incident response—culminating in your Production Capstone.

Week 11: Observability, Prometheus, Grafana & SRE Incident Management ​

LessonTopicCore Engineering Concepts
11.1The Three Pillars of Observability & Golden SignalsStructured JSON logs, metrics, distributed traces (OpenTelemetry concepts); Latency, Traffic, Errors, Saturation
11.2Centralised Structured LoggingShipping container logs to AWS CloudWatch Logs / Grafana Loki, correlation request_id tracing, PII redaction
11.3Metrics Collection with PrometheusPull model scraping, node_exporter, custom /metrics endpoints, Counter vs Gauge vs Histogram, PromQL queries (rate(), histogram_quantile())
11.4Executive & Engineering Dashboards in GrafanaVisualizing p95/p99 API latency, error rates, CPU/memory saturation, database connection pools, version annotations
11.5SLIs, SLOs, Error Budgets & AlertmanagerAvoiding alert fatigue, paging on user-impacting symptom breaches vs noisy CPU spikes, Slack/Email/Telegram webhook alerts
11.6Incident Response & Blameless Post-MortemsTriage runbooks, mitigation vs root-cause fix, 5 Whys analysis, writing actionable SRE post-mortem documents

Weekly Lab Milestone (Week 11) — Prometheus + Grafana Golden-Signals Stack & Post-Mortem: Deploy Prometheus, node_exporter, Alertmanager, and Grafana alongside your Compose/Cloud API, author p95 latency and 5xx error-budget alerts, and write a blameless SRE post-mortem following a simulated database connection exhaustion drill.


Week 12: Production Cloud & DevOps Capstone ​

MilestoneDeliverableEngineering Focus
12.1Architecture RFC & Threat/Cost ReviewNetwork topology diagram, CIDR layout, IAM role matrix, and monthly FinOps cost projection
12.2Containerisation & Local ParityHardened multi-stage Dockerfile (< 150 MB, non-root) + one-command local docker compose up stack
12.3Terraform Infrastructure ProvisioningRemote state backend, modular VPC/compute/database/registry HCL, passing terraform validate & Trivy IaC checks
12.4GitHub Actions CI/CD AutomationAutomated tests, container CVE gate, keyless OIDC auth, and zero-downtime deployment to live HTTPS custom domain
12.5Live Observability & Chaos DrillPrometheus + Grafana dashboard + live simulated failure injection during instructor review with documented post-mortem
12.6Capstone Defence & Portfolio PublicationLive architectural walkthrough, GitHub README runbook, and clean teardown script verification

Weekly Project 8 (Capstone) — End-to-End Automated, Observable Cloud Platform: Provision, deploy, monitor, and defend a production containerised web service + PostgreSQL + Redis architecture on AWS or Azure purely via Terraform and GitHub Actions, complete with HTTPS, least-privilege IAM, Prometheus/Grafana dashboards, alerting rules, FinOps budget guardrails, and an SRE operational runbook.


Assessment & Grading Breakdown ​

Every student is evaluated on real infrastructure repositories, working pipelines, security posture, and live troubleshooting—never multiple-choice memorisation alone.

Assessment ComponentWeightEvaluation Criteria
Weekly Lab Repositories & 7 Stage Projects40%Clean Linux/Bash automation, hardened multi-stage Dockerfiles, isolated Docker networks, AWS/Azure security groups, and reproducible documentation
Mid-Track Infrastructure & Security Audit30%Live practical diagnostic lab (fixing broken Nginx/DNS/IAM/Docker stacks under time constraints) + FinOps & IAM least-privilege review
Week 12 Production Cloud & DevOps Capstone30%Modular Terraform HCL, green GitHub Actions CI/CD pipeline with OIDC & Trivy gates, Prometheus/Grafana observability, and live chaos recovery

Learning Outcomes ​

Graduates of the Tech Minds Cloud Computing & DevOps programme can:

  1. Administer & Automate Linux Servers: Manage users, permissions, systemd daemons, ufw firewalls, SSH hardening, Nginx reverse proxies, and defensive Bash scripts on Ubuntu LTS servers.
  2. Containerise Full-Stack Systems: Author lean, non-root, multi-stage Dockerfiles and orchestrate isolated multi-container stacks (Nginx, API, PostgreSQL, Redis) using Docker Compose.
  3. Architect Secure AWS & Azure Environments: Design Multi-AZ VPCs/VNets, public/private subnets, load balancers, managed relational databases, object storage + CDNs, and serverless functions governed by IAM/RBAC least privilege.
  4. Ship Continuous Delivery Pipelines: Build GitHub Actions workflows incorporating automated tests, container vulnerability gates, keyless OIDC cloud authentication, and zero-downtime rollouts.
  5. Codify Cloud Infrastructure with Terraform: Write modular, DRY Terraform HCL backed by encrypted remote state, PR plan previews, and automated policy checks.
  6. Operate Reliable Production Services: Instrument applications with structured logs, Prometheus metrics, Grafana p95/p99 dashboards, SLO alerts, FinOps cost controls, and blameless incident post-mortems.

Tools, Platforms & Resources ​

CategoryTools CoveredPurpose in Curriculum
Operating System & ShellUbuntu 24.04 LTS, WSL2, GNU Bash, OpenSSH, tmuxServer administration, scripting, remote operations
Networking & EdgeNginx, Certbot (Let's Encrypt), dig, curl, ufw, ssReverse proxying, HTTPS termination, DNS & packet diagnostics
Containers & SecurityDocker Engine, Docker Compose, GitHub Container Registry, TrivyApplication packaging, local parity, image & IaC vulnerability scanning
Public Cloud ProvidersAmazon Web Services (AWS) & Microsoft AzureProduction compute, VPC/VNet networking, S3/Blob, RDS, serverless, IAM
CI/CD & Version ControlGit, GitHub, GitHub Actions (with OIDC federation)Automated testing, security gating, container builds, continuous deployment
Infrastructure as CodeHashiCorp Terraform (HCL), AWS CLI v2, Azure CLI (az)Declarative, version-controlled, repeatable cloud provisioning
Observability & SREPrometheus, Grafana, CloudWatch Logs, AlertmanagerMetrics scraping, PromQL dashboards, SLO alerting, incident triage

G5 Plaza (Before AEDC Office, Sabon-Gari Road), Bwari, Abuja, Nigeria · info@techmindsacademy.org · (+234) 814 732 8332