Kubernetes, Docker, and DevOps Interview Questions India 2026

Docker image vs container: image is a read-only, immutable template containing the application code, runtime, libraries, environment variables, and configuration. Container is a running instance of an image with its own isolated filesystem (overlayfs layers) and process namespace, sharing the host OS kernel (unlike VMs which have a full OS).

Dockerfile instructions: FROM (base image), COPY vs ADD (COPY: explicit file copy; ADD: also handles tar extraction and URLs), RUN (executes during build; each RUN creates a new layer; chain commands with && to reduce layers), CMD vs ENTRYPOINT (CMD: default arguments, overridden by docker run args; ENTRYPOINT: fixed executable, not overridden by default), ENV (environment variables available at build and run time), EXPOSE (documents the port; does not publish it), WORKDIR (sets the working directory for subsequent instructions).

Multi-stage builds: use a full build image (e.g. maven:3.9-openjdk-17) to compile and test, then COPY --from=builder only the compiled artifact to a minimal runtime image (e.g. eclipse-temurin:17-jre-alpine). Reduces production image size from 500MB+ to under 100MB. Critical for Kubernetes: smaller images pull faster, have smaller attack surface.

Docker Compose: defines multi-container applications via docker-compose.yml (services, networks, volumes). Use for local development to run the app + database + cache + message queue without Kubernetes overhead. Production: use Kubernetes instead of Compose.

Cluster components: control plane (API server: single point of entry for all kubectl commands and operators; etcd: consistent, distributed key-value store for all cluster state; scheduler: assigns pods to nodes based on resource requests, taints, and affinity rules; controller manager: runs controllers that reconcile desired vs actual state) and worker nodes (kubelet: runs on each node, ensures pods are running; kube-proxy: maintains iptables rules for service networking; container runtime: containerd or CRI-O).

Workload resources: Pod (smallest deployable unit: 1+ containers sharing network namespace and volume mounts), Deployment (manages stateless pods: desired replica count, rolling update strategy, rollback), StatefulSet (manages stateful pods: stable pod name (pod-0, pod-1), stable DNS identity, ordered creation and deletion, persistent storage per pod), DaemonSet (one pod per node: log collectors, monitoring agents, network plugins), Job (run to completion once), CronJob (scheduled Job).

Networking: Service (stable virtual IP (ClusterIP) that load-balances across pod replicas; types: ClusterIP (internal), NodePort (static port on each node), LoadBalancer (cloud provider load balancer), ExternalName (DNS alias)), Ingress (HTTP/HTTPS routing from outside the cluster to Services: path-based and host-based routing, TLS termination).

ConfigMap vs Secret: ConfigMap stores non-sensitive configuration as key-value pairs (database URL, feature flags); mounted as env vars or files. Secret stores sensitive data; base64-encoded at rest by default (not encrypted; use Sealed Secrets or KMS-backed encryption provider for true encryption).

HPA (Horizontal Pod Autoscaler): scales pod replicas based on CPU/memory utilisation or custom metrics (requests per second via Prometheus adapter); requires metrics-server.

CI vs CD vs CD: Continuous Integration = code merged frequently, automated tests run on every commit. Continuous Delivery = every passing build can be deployed at any time (deployment is manual). Continuous Deployment = every passing build is automatically deployed to production without manual approval.

Typical pipeline for an Indian product company: (1) Developer pushes to GitHub; webhook triggers GitHub Actions / GitLab CI / Jenkins pipeline. (2) Build stage: install dependencies, compile, run unit tests, build Docker image, push to ECR/DockerHub. (3) Static analysis: SonarQube code quality scan, Trivy container image vulnerability scan. (4) Deploy to staging: kubectl apply or Helm upgrade, Kubernetes rolling update. (5) Integration and E2E tests against staging. (6) Manual approval gate (for production deployments). (7) Deploy to production: rolling update with health checks; Kubernetes automatic rollback if readiness probe fails.

Helm: package manager for Kubernetes; a chart bundles all Kubernetes manifests (Deployment, Service, Ingress, ConfigMap) into a single versioned artifact with templating ({{ .Values.image.tag }}). helm upgrade --install for idempotent deployments. helm rollback for reverting to a previous release.

GitOps: ArgoCD or Flux watches a Git repository for changes to Kubernetes manifests or Helm charts and automatically applies them to the cluster. Desired state in Git; ArgoCD reconciles actual cluster state to match. Benefits: audit trail via git history, easy rollback via git revert, branch-based environments.

Preparation path: (1) Docker fundamentals (1 week): write Dockerfiles for a real application, build multi-stage images, run services with docker-compose, understand networking (bridge network, port mapping). (2) Kubernetes hands-on (2 weeks): use Killercoda (free browser-based Kubernetes lab) or kind/minikube locally; deploy an application with a Deployment, Service, and Ingress; scale it with HPA; simulate a rolling update and rollback. (3) Helm (3-4 days): convert Kubernetes manifests to a Helm chart; parameterise image tag and replica count. (4) GitHub Actions (3-4 days): write a workflow that builds a Docker image, runs tests, and pushes to a registry. (5) AWS EKS or GCP GKE (1 week): deploy a Kubernetes application to a managed cluster; configure a cloud load balancer Ingress.

What interviewers evaluate at different levels: Junior DevOps (0-2 years): Docker basics, Kubernetes Pod/Deployment/Service, simple GitHub Actions pipeline. Mid-level DevOps (2-5 years): Helm, ArgoCD/Flux (GitOps), monitoring stack (Prometheus + Grafana + Alertmanager), distributed tracing (Jaeger), on-call and incident response. Senior DevOps/SRE (5+ years): cluster capacity planning, multi-cluster architectures, service mesh (Istio), platform engineering, cost optimisation.