Top DevOps Engineer Interview Questions & Answers

Pipeline stages: 1. Source — Triggered on PR merge to main. Linting and commit message validation. 2. Build — Compile code, build Docker images with semantic versioning tags. 3. Test • Unit tests (run in parallel per service) • Integration tests (using docker-compose or testcontainers) • Security scanning (SAST with SonarQube, dependency audit) 4. Publish — Push Docker images to registry (ECR/GCR). Tag with commit SHA + semantic version. 5. Deploy to staging — Helm chart deployment to staging K8s cluster. Run smoke tests. 6. Deploy to production — Canary deployment (5% → 25% → 100%) with automated rollback on error rate spike. Key design principles: • Each service has its own pipeline (independent deployability) • Pipeline-as-code (Jenkinsfile or .github/workflows) — versioned alongside application code • Fail fast — linting and unit tests run first, expensive integration tests later • Immutable artifacts — same Docker image flows through all environments

Simple analogy: An image is a recipe; a container is the dish. • Image — A read-only template containing application code, runtime, libraries, and configuration. Built from a Dockerfile. Stored in registries (Docker Hub, ECR). • Container — A running instance of an image. Adds a writable layer on top. Has its own process space, network, and filesystem overlay. Key characteristics: • One image → many containers • Images are immutable; containers are ephemeral • Images are layered (each Dockerfile instruction creates a layer) — shared layers reduce storage and build time • Containers share the host OS kernel (unlike VMs which each run a full OS) Best practices: • Use multi-stage builds to reduce image size • Pin base image versions (don't use :latest in production) • Run as non-root user inside containers • One process per container

Self-healing mechanisms: 1. Liveness probes — K8s restarts containers that fail health checks 2. Readiness probes — K8s removes unhealthy pods from service endpoints (no traffic routed) 3. ReplicaSets — Maintain desired number of pod replicas. If a pod dies, a new one is scheduled automatically. 4. Node failure — Pod eviction and rescheduling to healthy nodes High availability architecture: • Control plane — Run 3+ API server replicas behind a load balancer. Use etcd cluster (3 or 5 nodes) for consensus. • Worker nodes — Spread pods across availability zones using pod anti-affinity rules. • Networking — Service mesh (Istio/Linkerd) for retries, circuit breaking, and observability. Key concept: K8s is a declarative system — you describe the desired state, and K8s continuously reconciles the actual state to match.

The three pillars of observability: 1. Metrics (Prometheus + Grafana) • System: CPU, memory, disk, network • Application: request rate, error rate, latency (RED method) • Business: orders/min, sign-ups, revenue 2. Logs (ELK Stack or Loki) • Structured JSON logging • Correlation IDs across microservices • Log levels: ERROR alerting, WARN for investigation 3. Traces (Jaeger or Datadog APM) • Distributed tracing across service boundaries • Identify bottleneck services and slow queries Alerting best practices: • Alert on symptoms (high error rate), not causes (high CPU) • Use severity tiers: P1 (page on-call), P2 (Slack notification), P3 (ticket) • Set meaningful thresholds — avoid alert fatigue • Runbooks for every alert (what to check, who to escalate to)