If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/iam-veeramalla/aws-devops-zero-to-hero shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Slowing — last commit 10mo ago

• Last commit 10mo ago
• 3 active contributors
• Apache-2.0 licensed
• ⚠ Slowing — last commit 10mo ago
• ⚠ Small team — 3 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 96% of recent commits
• ⚠ No CI workflows detected
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live iam-veeramalla/aws-devops-zero-to-hero repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/iam-veeramalla/aws-devops-zero-to-hero.

What it runs against: a local clone of iam-veeramalla/aws-devops-zero-to-hero — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in iam-veeramalla/aws-devops-zero-to-hero | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 327 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of iam-veeramalla/aws-devops-zero-to-hero. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/iam-veeramalla/aws-devops-zero-to-hero.git
#   cd aws-devops-zero-to-hero
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of iam-veeramalla/aws-devops-zero-to-hero and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "iam-veeramalla/aws-devops-zero-to-hero(\\.git)?\\b" \\
  && ok "origin remote is iam-veeramalla/aws-devops-zero-to-hero" \\
  || miss "origin remote is not iam-veeramalla/aws-devops-zero-to-hero (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "day-2/README.md" \\
  && ok "day-2/README.md" \\
  || miss "missing critical file: day-2/README.md"
test -f "day-14/simple-python-app/buildspec.yml" \\
  && ok "day-14/simple-python-app/buildspec.yml" \\
  || miss "missing critical file: day-14/simple-python-app/buildspec.yml"
test -f "day-24/main.tf" \\
  && ok "day-24/main.tf" \\
  || miss "missing critical file: day-24/main.tf"
test -f "day-22/installing-eks.md" \\
  && ok "day-22/installing-eks.md" \\
  || miss "missing critical file: day-22/installing-eks.md"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 327 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~297d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/iam-veeramalla/aws-devops-zero-to-hero"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

A 30-day structured AWS DevOps learning curriculum with hands-on projects covering EC2, VPC, IAM, ECS, EKS, Lambda, CloudWatch, and Infrastructure-as-Code. It teaches cloud-native deployment patterns through real examples: deploying Jenkins on EC2 (day-3), building VPC networking with security groups and NACLs (day-7), containerizing Python apps with Docker and CodeDeploy (day-14), monitoring with CloudWatch custom metrics (day-16), and orchestrating Kubernetes on EKS with ALB ingress controllers (day-22). The repo bundles Python automation scripts, Terraform infrastructure code, Docker images, and markdown walkthroughs aligned to a YouTube video series. Day-based directory structure: each day-N/ folder contains a focused topic (e.g., day-14/ covers CodeDeploy + Docker, day-22/ covers EKS setup). Within projects, typical layout is README.md (theory + steps), infrastructure code (main.tf, Dockerfile, appspec.yml), and runnable scripts (Python files with boto3 or shell scripts). No monorepo tooling; each day is largely standalone, encouraging learners to follow sequentially but allowing cherry-picking.

Junior and mid-level DevOps engineers and cloud infrastructure developers who want to move from zero AWS knowledge to hands-on proficiency in 30 days. Specifically targets learners who learn best through project-based examples (deploying a 2048 game app to EKS, writing Lambda functions, automating EBS snapshot cleanup) rather than conceptual lectures alone.

Actively maintained educational material, not a production library. The repo has real, working examples (Flask apps in day-21, Terraform configs in day-24, Python boto3 scripts in day-16/day-18/day-25) but is explicitly designed as a learning resource, not a framework. Lacks formal test suites and CI/CD pipelines (no GitHub Actions workflows visible), which is appropriate for a curriculum. The structure suggests regular updates tied to the YouTube series release cadence.

Standard open source risks apply.

The repo appears stable and complete for its original 30-day scope. No visible active development indicators in the file list (no open PR metadata, no recent commit timestamps, no GitHub Actions runs). The presence of specific, polished examples (day-21/app.py with requirements.txt, day-24/Terraform infra with userdata scripts, day-22/EKS setup with detailed markdown guides) suggests the core curriculum was completed and is now used as a reference.

git clone https://github.com/iam-veeramalla/aws-devops-zero-to-hero.git
cd aws-devops-zero-to-hero
# Follow day-1 README.md to set up AWS account and credentials
# Then proceed to day-2, day-3, etc. sequentially
# For any day with Python: pip install -r <day-N>/requirements.txt
# For any day with Terraform: cd day-N && terraform init && terraform plan

Daily commands: Depends on the day: Most days require AWS credentials configured (aws configure). For Python scripts: pip install -r day-N/requirements.txt && python day-N/script.py. For Terraform: terraform -chdir=day-N init && terraform -chdir=day-N apply. For Docker: docker build -t app day-N/simple-python-app && docker run -p 5000:5000 app. For EKS (day-22): follow day-22/installing-eks.md, then kubectl apply -f day-22/sample-app.md. Each day's README.md contains specific commands.

• README.md — Main entry point documenting the 30-day AWS DevOps learning curriculum and repository structure—every contributor must understand the learning progression and scope.
• day-2/README.md — IAM fundamentals documentation is foundational for all AWS security practices—critical for understanding access control patterns used throughout all subsequent days.
• day-14/simple-python-app/buildspec.yml — CodeBuild configuration defining the CI/CD pipeline for containerized applications—serves as the primary template for deployment automation across projects.
• day-24/main.tf — Terraform infrastructure-as-code for provisioning AWS resources at scale—demonstrates the infrastructure foundation pattern used in real-world DevOps workflows.
• day-22/installing-eks.md — EKS cluster setup documentation covering Kubernetes orchestration on AWS—essential for understanding container orchestration practices in modern DevOps.
• interview-questions/aws-cli.md — Consolidated AWS CLI interview questions and answers—reference material for understanding practical AWS command-line operations used throughout the curriculum.
• day-16/custom_metrics_demo/cloudwatch_metrics.py — CloudWatch custom metrics implementation demonstrating observability patterns—core example for monitoring and logging infrastructure in AWS.

Add a New Learning Day Module

1. Create a new day directory (e.g., day-26) in the repository root (day-26/README.md)
2. Write comprehensive README documenting learning objectives, key concepts, and hands-on examples for that AWS service (day-26/README.md)
3. Create subdirectories for demos, code samples, or infrastructure examples (e.g., demos/, terraform/, scripts/) (day-26/demos/)
4. Add practical Python or shell scripts demonstrating the service functionality with real-world use cases (day-26/demo_script.py)
5. Reference the new day in the main README.md with a brief description of the learning outcomes (README.md)

Add a New CI/CD Pipeline Project

1. Create application code in a new day directory structure with Python Flask/Django app (day-XX/app-name/app.py)
2. Create Dockerfile with multi-stage build pattern following day-14 and day-21 examples (day-XX/app-name/Dockerfile)
3. Create buildspec.yml defining CodeBuild steps for compilation, testing, and Docker image push to ECR (day-XX/app-name/buildspec.yml)
4. Create appspec.yml defining CodeDeploy configuration for rolling deployments with hooks (day-XX/app-name/appspec.yml)
5. Add start/stop container scripts following the pattern in day-14/simple-python-app/ (day-XX/app-name/start_container.sh)
6. Document deployment steps, testing procedures, and troubleshooting in day-XX/README.md (day-XX/README.md)

Add Infrastructure Terraform Module

1. Create main.tf defining AWS resources (VPC, Subnets, EC2, RDS, ALB) following day-24/main.tf pattern (day-24-modules/vpc-module/main.tf)
2. Create variables.tf with input variables for environment, instance count, CIDR blocks, and tags (day-24-modules/vpc-module/variables.tf)
3. Create provider.tf specifying AWS region and required provider versions (day-24-modules/vpc-module/provider.tf)
4. Add terraform.tfvars or example files documenting variable values for different environments (day-24-modules/vpc-module/terraform.tfvars)
5. Create README.md explaining module purpose, input/output variables, and usage examples (day-24-modules/vpc-module/README.md)

Add CloudWatch Monitoring Implementation

1. Create Python script in day-16 structure implementing custom metrics using boto3 CloudWatch client (day-16/new-service-metrics/cloudwatch_metrics.py)
2. Create requirements.txt specifying boto3 and other dependencies (day-16/new-service-metrics/requirements.txt)
3. Implement metric publishing following the pattern in day-16/custom_metrics_demo/cloudwatch_metrics.py (day-16/new-service-metrics/cloudwatch_metrics.py)
4. Add README.md documenting metric names, dimensions, and how to view them in CloudWatch console (day-16/new-service-metrics/README.md)

• AWS EC2 — Foundation for understanding virtual compute infrastructure and hosting containerized applications in the cloud.
• Docker & Containerization — Enables consistent application packaging and deployment across development, testing, and production environments.
• Terraform (IaC) — Allows declarative, version-controlled infrastructure provisioning and reproducible environment setup at scale.
• AWS CodePipeline/CodeBuild/CodeDeploy — Provides native AWS CI/CD automation eliminating manual deployment steps and enabling continuous delivery practices.
• Amazon EKS & Kubernetes — Enables container orchestration for managing microservices, scaling, and self-

AWS credentials: All Python scripts (day-16, day-18, day-25) assume ~/.aws/credentials or environment variables are configured; tests will silently fail if not. Terraform state: day-24 and day-22 examples use local state by default; multi-person learning requires S3 backend setup. Region-specific resources: Route 53 and EKS examples assume us-east-1 or specific availability zones—hardcoded region references in Terraform will fail in other regions. IAM permissions: day-7 EC2 instances need specific IAM roles (as mentioned in README) but role ARNs are not pre-created; learners must attach manually or add to Terraform. EKS cost: day-22 EKS cluster provisioning incurs AWS charges (~$0.10/hour control plane); README does not warn of this. Docker image sizes: day-14 and day-21 Dockerfiles use docker run without specifying image cleanup—learners may accumulate gigabytes of unused images. Deprecated Python 2: No explicit Python 3.8+ requirement stated, but boto3 in recent versions drops Python 2 support silently.

• Infrastructure as Code (IaC) — day-24 uses Terraform HCL to define VPC, EC2, security groups declaratively; this pattern is the DevOps standard for reproducible, version-controlled infrastructure instead of clicking the AWS console
• Identity and Access Management (IAM) policies and roles — day-2 and day-7 emphasize least-privilege access; understanding principal (user/role), resource, action, and condition JSON is critical for securing any AWS deployment (EC2, Lambda, ECS)
• Virtual Private Cloud (VPC) design patterns — day-4 and day-7 teach subnet isolation, route tables, and network ACLs; proper VPC segmentation (public subnets for load balancers, private for databases) is the foundation of secure multi-tier AWS architectures
• Container orchestration and declarative pod deployment — day-22 introduces EKS and Kubernetes manifests (day-22/sample-app.md defines Deployment and Service resources); understanding declarative YAML specs vs. imperative commands is essential for cloud-native DevOps
• CloudWatch custom metrics and monitoring — day-16 teaches pushing custom metrics (e.g., application-specific counters) via boto3; observability is non-negotiable for production systems, and CloudWatch is AWS's native solution
• CI/CD pipeline definitions (AppSpec and BuildSpec) — day-14 uses appspec.yml (CodeDeploy lifecycle) and buildspec.yml (CodeBuild steps); these declarative files automate testing, building, and deploying applications—the DevOps automation cornerstone
• DNS failover and health checks (Route 53) — day-6 covers Route 53's geolocation and failover routing policies; this enables high-availability architectures where traffic automatically reroutes if a primary endpoint fails

• hashicorp/terraform-aws-modules — Curated, production-grade Terraform modules for VPC, EC2, ECS, EKS that extend the day-24 and day-22 examples with best practices
• aws-samples/aws-cdk-examples — AWS CDK (Infrastructure as Code in Python/TypeScript) alternative to Terraform for the same day-24 infrastructure patterns, useful for learners who prefer Python over HCL
• kelseyhightower/kubernetes-the-hard-way — Deep-dive Kubernetes setup that complements day-22's managed EKS approach with understanding of what EKS abstracts away
• aws/aws-cli — Official AWS CLI repo—all day-N examples assume aws CLI; source reference for commands used throughout the curriculum
• boto/boto3 — Official boto3 library (Python SDK for AWS) used in day-16, day-18, day-25 scripts; learners debugging API calls should reference this

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add requirements.txt validation and Python environment setup documentation for day-14, day-16, day-21, and day-25

The repo contains multiple Python projects (day-14/simple-python-app, day-16/custom_metrics_demo, day-16/default_metrics_demo, day-21, day-25) with scattered requirements.txt files but no unified setup instructions or validation. This creates friction for learners following the 30-day curriculum. A PR should consolidate setup instructions and add a script to validate all Python environments can be installed.

• [ ] Create a root-level setup-python-environments.sh script that validates all requirements.txt files across day-14, day-16, day-21, day-25
• [ ] Update each day's README.md (day-14/README.md, day-16/README.md, day-21/README.md, day-25/README.md) with explicit 'Prerequisites' section listing Python version and pip install commands
• [ ] Add a .python-version file or comment in main README.md specifying minimum Python version (e.g., 3.8+)
• [ ] Document any conflicting dependencies (e.g., if Flask version differs between day-14/simple-python-app/requirements.txt and day-21/requirements.txt)

Create integration tests for day-24 Terraform infrastructure and day-2/day-8 IAM interview questions with practical examples

day-24 contains Terraform files (main.tf, provider.tf, variables.tf, userdata.sh) for AWS infrastructure but lacks validation tests. Additionally, day-2 and day-8 contain interview questions about IAM but no executable examples to verify answers. A PR should add Terraform validation and create runnable Python/Bash examples that demonstrate each IAM concept from the interview questions.

• [ ] Add terraform validate and terraform fmt checks in a test script for day-24/ (test-terraform.sh)
• [ ] Create day-2/terraform-iam-examples/ with Terraform code for 3-5 core IAM patterns (e.g., cross-account access, policy simulation) referenced in day-2/README.md interview questions
• [ ] Create day-8/iam-validation-examples/ with Python scripts using boto3 to demonstrate IAM concepts (users, groups, policies, roles) with assertions that validate expected behavior
• [ ] Add a section to day-2/README.md and day-8/Interview_q&a linking to these runnable examples

Add GitHub Actions CI workflow to validate Docker builds and Python code quality across day-14, day-21 Dockerfiles

The repo contains Dockerfiles (day-14/simple-python-app/Dockerfile, day-21/Dockerfile) and shell scripts (day-14/simple-python-app/start_container.sh, stop_container.sh) but no CI pipeline to catch build failures early. Contributors and learners will benefit from automated validation that Dockerfiles build successfully and Python code passes linting.

• [ ] Create .github/workflows/docker-build-validate.yml that runs 'docker build' for day-14/simple-python-app/Dockerfile and day-21/Dockerfile on every PR
• [ ] Add .github/workflows/python-lint.yml that runs pylint or flake8 on all .py files in day-14, day-16, day-21, day-25 directories
• [ ] Update root README.md with a 'CI/CD Status' badge and 'Contributing' section that mentions these automated checks
• [ ] Add a CONTRIBUTING.md file referencing these workflows and requirements for new contributions (e.g., 'PRs must pass Docker build and Python linting')

• Add Python requirements.txt pinning across all days: day-16/default_metrics_demo/requirements.txt, day-25/requirements.txt, and day-21/requirements.txt lack version pins. Pinning boto3>=1.26.0, Flask==2.3.0, etc. ensures scripts don't break on AWS API changes. Impact: ~15 minute contributor task, improves reliability for learners.: Prevents silent breakage when dependencies auto-update
• Document IAM role creation for day-7 project: day-7/README.md mentions 'create and assign IAM roles to instances with appropriate permissions' but doesn't provide the actual policy JSON or Terraform code. Add day-7/iam-role-template.tf with a reusable role definition. Impact: ~30 minutes, solves learner confusion on a critical networking lesson.: Reduces manual AWS console steps and makes the project fully reproducible with Terraform
• Add cost estimation to day-22 EKS guide: day-22/prerequisites.md should mention that EKS control plane costs $0.10/hour (~$73/month if left running). Add a day-22/cleanup.md with eksctl delete cluster --name <name> to prevent accidental charges. Impact: ~20 minutes, prevents learner surprises on their AWS bill.: Educational resource should warn of cost traps explicitly

Failed to generate security analysis.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.