Why Delhi NCR Students Are Choosing Cloud Computing in 2026

# main.tf — provisioning a real cloud environment with Terraform
# This is the kind of project that convinces interviewers you can build,
# not just talk about, cloud infrastructure.

terraform {
  required_version = ">= 1.6"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "ap-south-1"   # Mumbai — most Delhi NCR clients use this
}

# 1. Networking — a VPC with public and private subnets
resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  tags = {
    Name = "app-vpc"
  }
}

resource "aws_subnet" "public" {
  count                   = 2
  vpc_id                  = aws_vpc.main.id
  cidr_block              = "10.0.${count.index}.0/24"
  availability_zone       = data.aws_availability_zones.available.names[count.index]
  map_public_ip_on_launch = true
  tags = {
    Name = "app-public-${count.index}"
  }
}

resource "aws_subnet" "private" {
  count             = 2
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.${count.index + 10}.0/24"
  availability_zone = data.aws_availability_zones.available.names[count.index]
  tags = {
    Name = "app-private-${count.index}"
  }
}

# 2. Compute — an EC2 instance with a security group
resource "aws_security_group" "web" {
  name   = "app-web-sg"
  vpc_id = aws_vpc.main.id

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]   # tighten in production
  }

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

resource "aws_instance" "web" {
  ami                    = "ami-0c1a7f894efd4c6b4"   # Ubuntu 22.04 in ap-south-1
  instance_type          = "t3.micro"
  subnet_id              = aws_subnet.public[0].id
  vpc_security_group_ids = [aws_security_group.web.id]

  tags = {
    Name = "app-web"
  }
}

# 3. Storage — a private S3 bucket for artefacts
resource "aws_s3_bucket" "artifacts" {
  bucket = "app-artifacts-${random_id.suffix.hex}"

  tags = {
    Name = "app-artifacts"
  }
}

resource "random_id" "suffix" {
  byte_length = 4
}

resource "aws_s3_bucket_public_access_block" "artifacts" {
  bucket                  = aws_s3_bucket.artifacts.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

# 4. Outputs — the kind of details interviewers ask for
output "vpc_id" {
  value = aws_vpc.main.id
}

output "web_public_ip" {
  value = aws_instance.web.public_ip
}

output "bucket_name" {
  value = aws_s3_bucket.artifacts.bucket
}

# What an interviewer looks for:
# - Do you use modules and variables, or hardcoded values?
# - Do you understand VPC, subnets, security groups, and IAM?
# - Do you think about least privilege (S3 public access blocked)?
# - Can you explain why terraform state should be stored remotely?
# - Do you know what "ap-south-1" is and why it matters in India?
#
# This single project — with a README and a public plan output — is
# worth more than three certification PDFs.

# aws_cli_workflow.sh — a real day-in-the-life workflow of a cloud engineer
# The AWS CLI is one of the most underrated skills for cloud interviews.

#!/usr/bin/env bash
set -euo pipefail

# 1. Verify identity and account — first thing a cloud engineer does
echo "=== whoami ==="
aws sts get-caller-identity

# 2. List running EC2 instances in the account
echo "=== running instances ==="
aws ec2 describe-instances \
  --filters "Name=instance-state-name,Values=running" \
  --query "Reservations[*].Instances[*].[InstanceId,InstanceType,PublicIpAddress,Tags[?Key=='Name']|[0].Value]" \
  --output table

# 3. Check recent S3 bucket activity — useful when debugging
echo "=== S3 buckets ==="
aws s3 ls

# 4. Look at CloudWatch alarms that are currently firing
echo "=== firing alarms ==="
aws cloudwatch describe-alarms \
  --state-value ALARM \
  --query "MetricAlarms[*].[AlarmName,StateUpdatedTimestamp]" \
  --output table

# 5. Pull recent application logs to debug an incident
echo "=== recent error logs ==="
aws logs filter-log-events \
  --log-group-name "/aws/app/api" \
  --filter-pattern "ERROR" \
  --start-time "$(( $(date +%s000) - 3600000 ))" \
  --query "events[*].[timestamp,message]" \
  --output table | head -50

# 6. Estimate cost impact of a recent change
echo "=== cost forecast ==="
aws ce get-cost-forecast \
  --time-period Start="$(date +%Y-%m-01)",End="$(date -d '+1 month' +%Y-%m-01)" \
  --metric BLENDED_COST \
  --granularity MONTHLY \
  --output table

# What an interviewer looks for:
# - Do you know what STS is and why identity checks matter?
# - Can you use --query to filter CLI output (JMESPath)?
# - Do you understand filters vs tags vs state?
# - Can you read logs and alarms without an SRE tool?
# - Do you think about cost, not just uptime?
#
# This is the daily reality of a cloud support or cloud ops engineer.
# Freshers who know this well clear interviews faster than those
# who only know the console UI.

# Dockerfile + deployment — the standard cloud deployment pattern
# Every cloud role expects you to know how to containerise and deploy.

# --- Dockerfile ---
FROM python:3.12-slim

WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

# Run as non-root user — a real interview question
RUN useradd -r -u 1001 appuser
USER appuser

EXPOSE 8000

HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
  CMD python -c "import urllib.request; urllib.request.urlopen('http://localhost:8000/health')" || exit 1

CMD ["uvicorn", "app:app", "--host", "0.0.0.0", "--port", "8000"]

# --- ECS task definition (simplified) ---
{
  "family": "app-api",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "512",
  "memory": "1024",
  "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
  "containerDefinitions": [
    {
      "name": "api",
      "image": "123456789012.dkr.ecr.ap-south-1.amazonaws.com/app-api:latest",
      "portMappings": [{ "containerPort": 8000, "protocol": "tcp" }],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/app-api",
          "awslogs-region": "ap-south-1",
          "awslogs-stream-prefix": "ecs"
        }
      },
      "healthCheck": {
        "command": ["CMD-SHELL", "curl -f http://localhost:8000/health || exit 1"],
        "interval": 30,
        "retries": 3
      }
    }
  ]
}

# --- deploy.sh (using AWS CLI) ---
# 1. Build and tag
docker build -t app-api .
docker tag app-api:latest $ECR_REPO:latest
docker push $ECR_REPO:latest

# 2. Register new task definition
aws ecs register-task-definition --cli-input-json file://task-definition.json

# 3. Update the service
aws ecs update-service \
  --cluster app-cluster \
  --service app-api \
  --task-definition app-api \
  --force-new-deployment

# 4. Wait and verify
aws ecs wait services-stable --cluster app-cluster --services app-api

# Why this matters:
# - Containers + ECS/EKS is the standard way to deploy to cloud.
# - Health checks, logging, and non-root users are real interview questions.
# - A fresher who can explain this end-to-end stands out immediately.
# - Most Delhi NCR interviews ask "how do you deploy to production?" —
#   this is the answer.