DevOps Engineer with hands-on experience automating cloud infrastructure and CI/CD pipelines on Microsoft Azure. I design infrastructure as code with Terraform, deploy and secure containerized workloads on Azure Kubernetes Service (AKS), and build security scanning and observability directly into the delivery pipeline instead of bolting it on afterward. Currently extending this foundation into AWS through a self-driven infrastructure project.

• 🔧 Former DevOps Intern @ DevOps Insiders — provisioned and maintained Azure infrastructure across Dev, QA, and Staging
• 🌱 Building cross-cloud depth on AWS (VPC, EC2, ALB, IAM) through a personal landing-zone project
• 🎓 BCA, Chandigarh Group of Colleges, Mohali
• 📍 Noida, India
• 🎯 Looking for a full-time Junior DevOps / Cloud Engineer role

DevOps Intern — DevOps Insiders · 01 Aug 2025 – 15 Jul 2026

• Provisioned Azure infrastructure — Resource Groups, VNets, VMs, Storage Accounts, and Azure SQL Database — using Terraform across Development, QA, and Staging environments
• Deployed and maintained 6+ CI/CD pipelines using GitHub Actions and Azure DevOps Pipelines, automating build, test, validation, and deployment for internal applications
• Integrated terraform fmt, validate, TFLint, TFSEC, and Checkov into CI/CD pipelines for automated IaC validation and security checks
• Collaborated with a team of 5+ developers using Git Flow branching, pull requests, and code reviews for smooth code integration and deployments

🔗 Repo: azure-landing-zone-terraform Terraform Azure Firewall Bastion Key Vault Private DNS GitHub Actions

A hub-and-spoke enterprise network topology — the same pattern Microsoft recommends for real Azure landing zones — built entirely from reusable Terraform modules, with centralized security (Firewall + Bastion) and zero public exposure on workload VMs.

azure-landing-zone-terraform/
├── modules/
│   ├── networking/       # Hub + spoke VNets, subnets, peering
│   ├── firewall/         # Azure Firewall + rule collections
│   ├── bastion/          # Bastion host + NSG
│   ├── key-vault/        # Key Vault + private endpoint
│   └── storage/          # Remote state backend resources
├── environments/
│   ├── dev/
│   ├── qa/
│   └── staging/
├── .github/
│   └── workflows/
│       └── terraform.yml
├── main.tf
├── variables.tf
├── outputs.tf
└── README.md

• Fully modular Terraform — each network component is an independently testable, reusable module
• Environment isolation via separate .tfvars per environment (dev/QA/staging) on shared modules
• Reduced new-environment provisioning time from days to under 15 minutes

• Deny-by-default NSGs on every spoke subnet
• Zero public IPs on workload VMs — access only via Bastion
• Key Vault reachable only through a private endpoint
• Centralized egress/ingress inspection through Azure Firewall

PR opened → GitHub Actions runs terraform fmt + validate + plan → plan output posted for review → manual approval gate → terraform apply on merge.

terraform init -backend-config=environments/dev/backend.tfvars
terraform plan -var-file=environments/dev/dev.tfvars
terraform apply -var-file=environments/dev/dev.tfvars

Designing for peered networks forced me to think in terms of blast radius and centralized control points rather than per-VM security — the firewall and Bastion become the two chokepoints everything must pass through.

• Add Azure Policy for automated compliance enforcement across spokes
• Integrate Private DNS Resolver for hybrid on-prem resolution
• Add a 3rd spoke for a shared-services tier (DNS, patch management)

🔗 Repo: aks-devsecops-pipeline AKS Docker Kubernetes Helm Trivy SonarQube Prometheus Grafana GitHub Actions

A commit-to-cluster pipeline for a 4-service application where security and quality gates block the deploy, not just warn about it — paired with live pod-health observability post-deploy.

aks-devsecops-pipeline/
├── services/
│   ├── service-1/
│   ├── service-2/
│   ├── service-3/
│   └── service-4/
├── helm/
│   ├── Chart.yaml
│   ├── values-dev.yaml
│   ├── values-prod.yaml
│   └── templates/
│       ├── deployment.yaml
│       ├── service.yaml
│       └── ingress.yaml
├── monitoring/
│   ├── prometheus-values.yaml
│   └── grafana-dashboards/
├── .github/
│   └── workflows/
│       └── ci-cd.yml
└── README.md

• Parallel multi-service builds to keep pipeline time down
• Helm-driven pod scaling, service config, and ingress rules — no manual kubectl apply
• Full commit-to-deploy automation, merged PR to running pod on AKS in under 10 minutes

• Trivy blocks any image with a critical/high CVE from being deployed
• SonarQube enforces a quality gate (coverage, code smells, duplication) before merge
• No manual production deploys — everything routed through the pipeline

Merge to main → Docker build → Trivy + SonarQube gates (parallel) → both must pass → Helm upgrade/install → AKS rollout → Prometheus starts scraping new pods.

• Prometheus scrapes CPU/memory/pod-restart metrics from the cluster
• Grafana dashboards track per-service health and resource usage
• Alerting rules configured for pod crash-loop and high resource utilization

docker build -t registry/service-1:$(git rev-parse --short HEAD) ./services/service-1
trivy image registry/service-1:latest --severity CRITICAL,HIGH --exit-code 1
helm upgrade --install my-app ./helm -f helm/values-prod.yaml --namespace production
kubectl get pods -n production -w

Treating security scans as hard gates rather than advisory reports was the biggest shift — it forces you to fix vulnerabilities before they ever reach a cluster, not patch them after the fact.

• Add canary/blue-green rollout strategy via Argo Rollouts
• Add distributed tracing (OpenTelemetry) across the 4 services
• Externalize secrets to Azure Key Vault via CSI driver instead of K8s secrets

🔗 Repo: aws-terraform-landing-zone-project Terraform VPC EC2 ALB IAM S3 DynamoDB

A self-driven project to build AWS depth using the same "no direct internet exposure" principle as the Azure landing zone — multi-AZ, private compute, and locked-down remote state.

📎 Full write-up and AWS Console deployment screenshots are in the repo's README.

aws-terraform-landing-zone-project/
├── modules/                # VPC, ALB, EC2, IAM, etc. as reusable modules
├── environments/            # Environment-specific variable files
├── bootstrap/                # One-time setup for S3 + DynamoDB remote state
├── diagrams/
│   ├── architecture.png
│   └── README.md
├── images/                   # AWS Console screenshots (deployment proof)
│   ├── aws-subnets.png
│   ├── ec2-instance.png
│   ├── application-load-balancer.png
│   ├── alb-details.png
│   └── target-group-health.png
├── .github/
│   └── workflows/
├── backend.tf
├── main.tf
├── outputs.tf
├── providers.tf
├── variables.tf
├── versions.tf
└── README.md

• Multi-AZ design for basic high availability on the compute tier
• Fully private compute layer — EC2 instances have no public IPs
• Remote state with locking, safe for team/CI use without state corruption

• Security groups scoped to ALB-only ingress on EC2
• IAM instance roles scoped to only the permissions the instance needs
• No inbound internet path to compute — only outbound, via NAT

PR opened → GitHub Actions runs terraform fmt → validate → plan → plan posted on PR for review → apply on approval/merge.

terraform init
terraform fmt -check
terraform validate
terraform plan -var-file=environments/dev/dev.tfvars
terraform apply -var-file=environments/dev/dev.tfvars

Setting up S3 + DynamoDB remote state from scratch made the "why" behind state locking concrete — without it, two people (or two pipeline runs) applying at once can corrupt state.

• Add Auto Scaling Group instead of fixed EC2 count
• Add AWS WAF in front of the ALB
• Migrate compute to ECS Fargate to remove instance management entirely

Bachelor of Computer Applications (BCA) — Chandigarh Group of Colleges, Mohali · CGPA: 7.63/10

📈 GitHub profile stats — click to expand

Always happy to connect with fellow DevOps engineers and recruiters — feel free to reach out!