DevOps and SRE Interview Questions India 2026: CI/CD, Kubernetes, Monitoring, and Incident Management

CI/CD and containerization questions:

1. 'What is the difference between continuous integration, continuous delivery, and continuous deployment?' Continuous Integration (CI): developers merge code to a shared branch frequently (daily); automated build + tests run on every merge. Goal: catch integration errors early. Continuous Delivery (CD): every passing build is automatically delivered to a staging environment and is ready for production release with a manual approval step. Continuous Deployment: every passing build is automatically deployed to production with no manual step. Most Indian companies practice CI + Continuous Delivery (not full deployment) for production safety.

2. 'What are Docker best practices?' Use official minimal base images (node:20-alpine over node:20). Multi-stage builds: builder stage (compile/install build tools) + production stage (copy only the output). Order Dockerfile instructions from least to most frequently changed to maximise layer caching (COPY package.json . before COPY . .). Use .dockerignore to exclude node_modules, .git, and test files. Never run containers as root; add 'RUN adduser -D appuser && USER appuser'. Use COPY instead of ADD unless you need auto-extraction of tarballs.

3. 'What is Docker Compose?' Docker Compose defines and runs multi-container applications from a YAML file. Use for local development (run app + database + Redis + Nginx together with 'docker compose up'). Not for production Kubernetes; use Helm charts for Kubernetes workloads.

4. 'What is the difference between CMD and ENTRYPOINT in a Dockerfile?' CMD: the default command to run if no command is specified at 'docker run'. Can be overridden by passing a command to 'docker run'. ENTRYPOINT: the fixed executable the container always runs; CMD then provides default arguments to ENTRYPOINT. Common pattern: ENTRYPOINT ["node"], CMD ["server.js"]; running 'docker run image debug.js' overrides CMD but keeps the ENTRYPOINT.

Kubernetes interview questions:

1. 'Explain the Kubernetes control plane components.' kube-apiserver: REST API frontend; every client (kubectl, controllers, kubelet) communicates through it. etcd: distributed key-value store for all cluster state; the single source of truth. kube-scheduler: assigns pods to nodes based on resource requests, node selectors, affinity rules. kube-controller-manager: runs reconciliation loops (Deployment controller, ReplicaSet controller, Node controller). cloud-controller-manager: manages cloud-provider resources (AWS ELB, GCP load balancers, Azure disks).

2. 'What is the difference between a Deployment and a StatefulSet?' Deployment: stateless pods; pods are interchangeable (pod-abc-xyz, pod-def-uvw); rolling updates; no stable network identity; all pods share the same PersistentVolumeClaim if mounted. StatefulSet: stateful applications (databases, Kafka, Zookeeper); each pod has a stable hostname (pod-0, pod-1); pods created/deleted in order (pod-0 before pod-1); each pod gets its own PersistentVolumeClaim.

3. 'What is a Kubernetes Service?' A Service provides a stable network identity for a dynamic set of pods (selected by label). ClusterIP (default): internal only. NodePort: exposes on each node's IP at a static port. LoadBalancer: creates an external cloud load balancer. ExternalName: maps to a DNS name.

4. 'What is a HorizontalPodAutoscaler (HPA)?' HPA automatically scales pod replica count based on observed CPU/memory utilisation or custom metrics (from a metrics server or Prometheus adapter). 'kubectl autoscale deployment my-app --cpu-percent=70 --min=2 --max=10': scale up when average CPU > 70%, between 2 and 10 replicas.

5. 'What is Helm?' Helm is a package manager for Kubernetes. Helm charts bundle Kubernetes manifests as templates with configurable values. 'helm install my-release my-chart -f values.yaml' deploys the chart with custom values. Helm manages upgrades ('helm upgrade') and rollbacks ('helm rollback').

SRE interview questions on observability and incidents:

1. 'What is the difference between SLI, SLO, and SLA?' SLI (Service Level Indicator): a specific metric measuring the service's health. Common SLIs: availability (% successful requests), latency (p99 response time), error rate (% requests that result in an error). SLO (Service Level Objective): a target value for an SLI over a time window. Example: 99.9% of requests succeed in a 30-day rolling window. SLA (Service Level Agreement): a contractual commitment to a customer with financial penalties if breached. Typical SLO is stricter than the SLA (giving you an internal error budget before the SLA is at risk).

2. 'What are the four golden signals?' Latency: time to serve a request (track successful and error latency separately; a fast error is misleading). Traffic: demand on the system (RPS, events/second, batch throughput). Errors: rate of failed requests (5xx, timeouts, wrong results). Saturation: how full the most constrained resource is (CPU, memory, disk, network queue). These four cover what matters for most services before more specialised metrics are needed.

3. 'How do you handle a production incident?' Detect: alert fires from monitoring (Prometheus + Alertmanager, Datadog, Grafana). Triage: determine severity (SEV-1: total outage; SEV-2: major feature broken; SEV-3: minor degradation). Assemble incident response: incident commander (coordinates), comms lead (updates stakeholders), technical lead (investigates). Mitigate first: rollback the last deployment, toggle the feature flag, shift traffic away from the failing region. Root cause analysis: after mitigation, investigate logs, metrics, and traces for the root cause. Blameless postmortem: document timeline, root cause, contributing factors, and action items with owners and deadlines.

Terraform IaC interview questions:

1. 'What is Terraform and what problem does it solve?' Terraform is an open-source Infrastructure-as-Code (IaC) tool by HashiCorp. It allows you to define infrastructure (VMs, databases, load balancers, DNS records, IAM policies) in declarative HCL code. Benefits: version-controlled infrastructure, reproducible environments, drift detection, and multi-cloud support (AWS, GCP, Azure, Kubernetes all via providers).

2. 'What is the Terraform state file?' The state file ('terraform.tfstate') maps Terraform resources to real infrastructure. It is how Terraform knows what exists so it can plan updates and deletions. Store state remotely (S3 + DynamoDB for locking, GCS, Terraform Cloud) in team environments to prevent concurrent modification. Never commit state files to Git (they contain sensitive resource IDs and sometimes secrets).

3. 'What is the difference between terraform plan and terraform apply?' terraform plan: shows what changes Terraform will make without applying them (add, change, destroy). Always review the plan before apply. terraform apply: applies the planned changes to real infrastructure. '-auto-approve' skips the confirmation prompt (use with caution in pipelines).

4. 'What is a Terraform module?' A module is a reusable collection of Terraform resources grouped for a common purpose (e.g., a VPC module, an EKS cluster module). Modules promote DRY principles; you call the module with input variables and it creates the resources. The root module is your main configuration; child modules are called within it.