DevOps Engineer Technical Interview Questions & Answers (2026)

I'd design a pipeline with these stages: 1) Source: trigger on PR merge to main via GitHub webhooks. 2) Build: Docker multi-stage build for each changed service, push to a private container registry with git SHA tags (never 'latest'). 3) Unit tests run in parallel per service. 4) Security: Trivy scans container images, Snyk checks dependencies, and SAST tools scan code. Pipeline fails on critical vulnerabilities. 5) Deploy to staging with Helm charts, run integration tests against staging with realistic test data. 6) Manual approval gate for production (or automatic for non-critical services). 7) Production canary deployment: deploy new version to 5% of pods, monitor error rates and latency for 10 minutes. If metrics are healthy, gradually roll to 25%, 50%, 100%. Automatic rollback if error rate exceeds 2x baseline. I'd use ArgoCD for GitOps-based deployment so the desired state is always in Git. The pipeline runs in GitHub Actions with self-hosted runners for speed. Key design decisions: immutable images (no runtime configuration changes), environment-specific values in sealed secrets, and deployment manifests versioned alongside application code.

I'd start by understanding the scope: what percentage of requests are affected? Is it all endpoints or specific ones? Are specific users/regions affected? Which services are in the request path? Step 1: Check the load balancer metrics — is it timing out waiting for the backend, or is the backend responding slowly? ALB access logs show response times per target. Step 2: If the backend is slow, check application metrics: CPU, memory, garbage collection, thread pool exhaustion. Step 3: Check database metrics: query latency, connection pool usage, slow query log. Many 504s trace back to database contention. Step 4: Check downstream dependencies: if the app calls external APIs, are those timing out? Check circuit breaker states. Step 5: Look for temporal patterns — does it happen at specific times (cron jobs? batch processing?) or correlate with traffic spikes? Step 6: Check recent deployments — did anything change in the last 24-48 hours? Step 7: If all metrics look normal, check for network issues: DNS resolution times, TCP retransmissions, and network policy changes. Common culprits for intermittent 504s: connection pool exhaustion, DNS resolution spikes, ephemeral port exhaustion, or a downstream service that occasionally slows down. I'd correlate the 504 timestamps across all metrics to find the common thread.

Deployments manage stateless applications: all pods are interchangeable, can be scaled horizontally, and are created/destroyed in any order. Pods get random names (app-7d9f4b5-x2kl). Rolling updates replace pods gradually. Use for: web servers, API services, workers — anything where pods don't need stable identity or persistent storage. StatefulSets manage stateful applications with guarantees: stable network identities (pod-0, pod-1, pod-2), ordered deployment and scaling (pod-0 must be running before pod-1 starts), and persistent volume claims that survive pod restarts. Use for: databases (PostgreSQL, MySQL), message brokers (Kafka, RabbitMQ), and distributed systems requiring stable peer discovery (Elasticsearch, Consul). DaemonSets ensure one pod runs on every node (or a subset of nodes matching a selector). Pods are automatically added when new nodes join and removed when nodes are drained. Use for: log collectors (Fluentd), monitoring agents (Prometheus node exporter), network plugins (Calico), and storage drivers. The key decision framework: need stable identity or persistent storage → StatefulSet. Need one per node → DaemonSet. Everything else → Deployment. In practice, 90% of workloads are Deployments.

I'd use Terraform with these design principles: 1) Repository structure: separate directories for each environment (dev, staging, prod) with a shared modules directory. Each environment has its own state file and backend configuration. 2) Module design: reusable modules for common patterns — VPC module (subnets, NAT gateways, route tables), EKS module (cluster, node groups, IRSA), RDS module (instance, parameter groups, security groups). Modules expose only necessary variables and outputs. 3) State management: remote state in S3 with DynamoDB locking. One state file per environment, never shared. State should be treated as sensitive (it contains resource IDs and sometimes secrets). 4) Secret management: never store secrets in Terraform state or code. Use AWS Secrets Manager with data sources, or sealed-secrets for Kubernetes. 5) CI/CD: Terraform plans run on every PR with Atlantis or GitHub Actions. Plan output is posted as a PR comment for review. Apply requires approval and runs only from CI (never local laptops). 6) Tagging strategy: all resources tagged with environment, team, cost-center, and managed-by=terraform. 7) I'd start with the VPC and networking module, then add compute, then data stores — building bottom-up so each layer can reference the one below.

I follow the three pillars approach: metrics, logs, and traces. Metrics (Prometheus/Datadog): I'd implement USE method for infrastructure (Utilization, Saturation, Errors for CPU, memory, disk, network) and RED method for services (Rate, Errors, Duration for each endpoint). Key metrics: request rate, error rate, p50/p95/p99 latency, pod restarts, and custom business metrics (orders/minute, signups/hour). Logs (ELK/Loki): structured JSON logging with correlation IDs that span services. Log levels enforced: ERROR for actionable issues, WARN for degraded performance, INFO for request flows. Never log PII. Traces (Jaeger/Tempo): distributed tracing across microservices to identify latency bottlenecks and failure propagation. For alerting philosophy: alert on symptoms (high error rate, slow latency) not causes (high CPU). Every alert must be actionable — if there's no action to take, it's a dashboard metric, not an alert. I use severity levels: P1 (customer-impacting, wake someone up), P2 (degraded, address during business hours), P3 (informational, review weekly). I'd also implement SLO-based alerting: define an error budget (e.g., 99.9% availability = 43 minutes/month of downtime) and alert when we're burning through it faster than expected. This prevents alert fatigue from transient spikes while catching sustained degradation.