Capstone — Submit IaC Repo with Passing CI Pipeline and Live URL — Infrastructure as Code

Project Submission Requirements

The Course 2 capstone project is your comprehensive demonstration of Infrastructure as Code competency. You will submit a Git repository that implements the complete cricket analytics platform IaC pipeline, meeting all requirements below. The project is graded on correctness (does the infrastructure deploy and work?), security (do all Checkov HIGH checks pass?), quality (does all CI pass with green checks?), operations (is the playbook idempotent?), and completeness (are all required components present?).

Analogy🏏Cricket

🏏 Think of it like cricket: This is the World Cup Final — every preparation session, every practice match, every training drill has built to this moment, and the submission requirements are simply the tournament's entry conditions made explicit. The repository is your squad walking out: complete, named, and organised (Terraform modules, Ansible roles, workflows, README — the structure itself is graded, because a selector reads how a team is assembled before watching it play). The passing CI pipeline is the match officials' clearance certificate: five independent desks — formatting, validity, lint, security, plan — have each stamped the paperwork, and the stamps are machine-verified on your actual repository, not claimed in prose (a green tick on a real PR is evidence; 'it passes locally' is an anecdote). The live URL is the final itself: the ball actually bowled, under lights, in front of the crowd — infrastructure genuinely provisioned, configured and serving, because in this discipline a design that has never run is a team that has never played. And the idempotent re-run requirement (terraform plan showing no changes, the second Ansible pass reporting changed=0) is the champion team's defining trait: composure — asked to perform again under scrutiny, it repeats the result exactly, changing nothing, proving the outcome was engineered rather than lucky. Submit the way champions arrive at finals: nothing left to chance, everything already verified.

Mandatory Requirements

✅ Terraform: VPC module, ALB with HTTPS, EC2 Auto Scaling Group, RDS PostgreSQL (lifecycle prevent_destroy=true), S3 data bucket (lifecycle prevent_destroy=true), KMS keys, security groups, IAM roles
✅ Checkov: All HIGH severity checks pass — zero unsuppressed HIGH findings; any suppressed findings have inline justification comments
✅ CI Pipeline: GitHub Actions with five-stage PR quality gate (fmt → validate → tflint → Checkov → plan with PR comment) and main-branch apply pipeline
✅ Ansible: Three roles (cricket_common, cricket_nginx, and either cricket_app_deploy or cricket_os_hardening) with Molecule tests; site playbook applying roles to correct host groups
✅ Idempotency: CI pipeline includes idempotency verification step; second playbook run produces changed=0
✅ Live URL: A URL that returns HTTP 200 from the ALB (the health endpoint '/health' returns JSON)
✅ State management: Remote S3 backend with DynamoDB locking, encryption enabled
✅ Documentation: README.md explaining the architecture, how to deploy, and how to run tests

Submission Checklist

Before submitting, verify each requirement independently. Run 'terraform plan' and verify zero errors. Run 'checkov -d . --framework terraform --severity HIGH' and verify zero failures. Open a PR to your own repository and verify all five CI stages show green checkmarks. Merge the PR and verify the apply pipeline succeeds. Run the Ansible playbook twice against the deployed instances and verify changed=0 on the second run. Curl the ALB DNS name's /health endpoint and verify a 200 response with valid JSON. Run 'terraform destroy' and verify that it fails with prevent_destroy errors for RDS and S3. Share the repository URL and live ALB URL with the grader. A complete, working submission earns full marks — partial submissions are graded proportionally based on the fraction of requirements met.

Analogy🏏Cricket

🏏 Think of it like cricket: The pre-submission checklist is the umpires' own pre-match ritual — and note WHO performs it: the officials check their equipment before the match, rather than discovering a dead light meter in the middle of a review. Every item on the list re-runs one of the course's verification tools against your finished repository exactly as the grader will (terraform plan clean, Checkov zero HIGH findings, all five CI stages green on a real PR, the second Ansible run reporting changed=0, the live URL answering) — so by the time you submit, there is nothing left for the grader to discover that you have not already observed yourself. This is the professional habit the capstone is really examining, more than any single technology: engineers who verify their own work against the acceptance criteria before handing it over are the ones trusted with production, because 'it should work' and 'I watched it work' are different claims, and only one of them survives contact with a grader, a code reviewer, or a 2 a.m. incident. Run the script, watch every check pass, and submit the way a good match official takes the field — having personally confirmed, that morning, that every piece of equipment they will rely on actually works.

bash

#!/bin/bash
# Pre-submission verification script
set -euo pipefail

echo '=== Pre-submission checklist ==='

echo '1. Terraform plan passes...'
cd environments/production
terraform plan -no-color 2>&1 | tail -5

echo '2. Checkov HIGH findings...'
pip install -q checkov
CHECKOV_OUTPUT=$(checkov -d ../.. --framework terraform --severity HIGH --quiet 2>&1)
HIGH_FAILURES=$(echo "$CHECKOV_OUTPUT" | grep 'Failed checks' | awk '{sum+=$3}END{print sum+0}')
echo "HIGH failures: ${HIGH_FAILURES}"
[[ $HIGH_FAILURES -eq 0 ]] && echo 'PASS' || echo 'FAIL — resolve all HIGH findings'

echo '3. GitHub Actions CI all green...'
gh run list --limit 5 --json conclusion,name 2>/dev/null | \
  python3 -c "import sys,json; runs=json.load(sys.stdin); [print(f'  {r[\"name\"]}: {r[\"conclusion\"]}') for r in runs]"

echo '4. Live URL check...'
ALB_DNS=$(terraform output -raw alb_dns_name 2>/dev/null || echo 'ALB_DNS_NOT_YET_AVAILABLE')
curl -sf "https://${ALB_DNS}/health" 2>/dev/null | python3 -m json.tool && echo 'PASS' || echo 'FAIL or ALB not ready'

echo '5. prevent_destroy verification...'
terraform plan -destroy 2>&1 | grep -E 'prevent_destroy|cannot be destroyed' | head -5

echo '6. Ansible idempotency...'
cd ../../ansible
ansible-playbook -i inventory/aws_ec2.yml site.yml 2>&1 | grep 'changed=' | \
  awk '{for(i=1;i<=NF;i++) if($i~/changed=/) print $i}' | \
  awk -F= '{sum+=$2}END{print "Total changed:",sum+0}'

echo
echo '=== All checks complete. Review results above before submitting. ==='

Congratulations on completing Course 2 — Infrastructure as Code: Terraform and Ansible! You have covered the full IaC spectrum: HCL fundamentals and the Terraform workflow, module design and remote state management, security scanning and testing, Ansible inventory and playbook authoring, role-based configuration management, and the complete CI/CD pipeline that ties everything together. The skills from this course are directly applicable to production cloud engineering roles. Course 3 — Containers: Docker and Kubernetes — builds on this foundation, adding container orchestration to the IaC toolkit and completing the cloud-native engineering skill set.

Capstone — Submit IaC Repo with Passing CI Pipeline and Live URL

Project Submission Requirements

Mandatory Requirements

Submission Checklist

Submit your capstone project