DevOps & SRE Interview Guide 2026: Infrastructure, CI/CD, Kubernetes, and Incident Response

Complete preparation guide for DevOps and Site Reliability Engineering interviews covering Kubernetes, Terraform, CI/CD pipeline design, observability, incident management, and real troubleshooting scenarios.

DevOps/SRE Interview Overview: What Companies Actually Evaluate

DevOps and SRE roles sit at the intersection of software engineering and operations. Interviews test a unique combination of skills:

1. Infrastructure Design (30%) — Cloud architecture, networking, security
2. Automation & CI/CD (25%) — Pipeline design, IaC, GitOps
3. Reliability & Incident Response (25%) — SLOs, monitoring, troubleshooting
4. Coding/Scripting (20%) — Python/Go/Bash automation, tool building

The key difference from software engineering interviews: you're expected to think about PRODUCTION from minute one. Failure modes, scaling, cost, security, and observability should be part of every answer.

Kubernetes (Asked at 90% of DevOps/SRE Interviews)

Core Concepts You Must Know

Architecture:

• Control Plane: API Server, etcd, Scheduler, Controller Manager
• Worker Nodes: kubelet, kube-proxy, container runtime
• Pod lifecycle: Pending → Running → Succeeded/Failed
• Service types: ClusterIP, NodePort, LoadBalancer, ExternalName

Workload Resources:

• Deployment: Stateless apps, rolling updates, rollback
• StatefulSet: Stateful apps, stable network identities, ordered deployment
• DaemonSet: One pod per node (monitoring agents, log collectors)
• Job/CronJob: Batch processing, scheduled tasks

Networking:

• Service discovery (DNS-based: service-name.namespace.svc.cluster.local)
• Ingress controllers (Nginx, Traefik, AWS ALB)
• Network Policies (pod-to-pod firewall rules)
• CNI plugins (Calico, Cilium, Flannel)

Storage:

• PersistentVolume (PV) and PersistentVolumeClaim (PVC)
• StorageClasses and dynamic provisioning
• ReadWriteOnce vs ReadWriteMany access modes
• CSI drivers for cloud-specific storage

Kubernetes Interview Questions (With Expert Answers)

Q: How would you implement zero-downtime deployments in Kubernetes?

A: Use Deployment with RollingUpdate strategy. Configure:

• maxSurge: 25% (create new pods before killing old)
• maxUnavailable: 0 (never have fewer than desired pods)
• readinessProbe: Ensure new pods are ready before receiving traffic
• preStop hook: Allow in-flight requests to complete before termination
• PodDisruptionBudget: Prevent voluntary disruptions from violating availability

Q: A pod is in CrashLoopBackOff. How do you debug it?

A: Systematic approach:

1. kubectl describe pod <name> — Check Events section for scheduling/pulling errors
2. kubectl logs <pod> --previous — See logs from the crashed container
3. Check resource limits — OOMKilled means memory limit too low
4. Check readiness/liveness probes — misconfigured probes cause restart loops
5. kubectl exec -it <pod> -- /bin/sh (if it stays up briefly) — investigate filesystem/configs
6. Check dependent services — DB connection strings, secrets mounting, DNS resolution

Q: How do you handle secrets in Kubernetes?

A: Multi-layered approach:

1. Never store secrets in Git or ConfigMaps
2. Use Kubernetes Secrets (base64 encoded, not encrypted at rest by default)
3. Enable encryption at rest (EncryptionConfiguration with AES-CBC or KMS)
4. External secret management: HashiCorp Vault, AWS Secrets Manager, or GCP Secret Manager
5. Inject via ExternalSecrets Operator or CSI Secret Store Driver
6. Rotate secrets automatically, audit access via RBAC

Helm and GitOps

Helm:

• Understand Chart structure (Chart.yaml, values.yaml, templates/)
• Template functions ({{ .Values.x }}, {{ include }}, {{ if }})
• Helm hooks (pre-install, post-upgrade, pre-delete)
• Values management (per-environment overrides)

GitOps (ArgoCD/Flux):

• Git as single source of truth for infrastructure state
• Automatic sync: change in Git → automatic deployment
• Drift detection: alert when cluster state differs from Git
• App of Apps pattern for managing multiple services

Terraform and Infrastructure as Code

Core Concepts

State management:

• Terraform state tracks what resources exist and their properties
• Remote state backends (S3 + DynamoDB lock, Terraform Cloud)
• State locking prevents concurrent modifications
• terraform import for adopting existing resources
• State surgery (terraform state mv, terraform state rm) — know when and how

Modules:

• Reusable infrastructure components
• Input variables, output values
• Module versioning and registry
• Composition pattern (root module calls child modules)

Workspaces vs Environments:

• Workspaces: Same config, different state (dev/staging/prod)
• Alternative: Separate directories per environment with shared modules
• When to use which: Workspaces for identical infra, directories for different architectures

Terraform Interview Questions

Q: How do you handle Terraform state drift?

A:

1. Run terraform plan regularly (CI/CD on schedule) to detect drift
2. Investigate: was the drift intentional (emergency hotfix) or accidental?
3. If intentional: update Terraform code to match reality, then terraform apply
4. If accidental: terraform apply to enforce desired state
5. Prevention: enforce all changes through Terraform (deny console access in prod), use Sentinel/OPA policies

Q: How do you manage secrets in Terraform?

A:

1. Never commit secrets in .tf files or terraform.tfvars
2. Use environment variables (TF_VAR_db_password)
3. Reference secrets from Vault/AWS Secrets Manager using data sources
4. Mark sensitive outputs with sensitive = true
5. Encrypt state file (remote backend with encryption)
6. Use SOPS or age for encrypting variable files in Git

CI/CD Pipeline Design

Modern Pipeline Architecture

Stages:

1. Source — Git push triggers pipeline (webhook or poll)
2. Build — Compile, Docker build, artifact creation
3. Test — Unit tests, integration tests, contract tests
4. Security Scan — SAST (code), SCA (dependencies), container scan
5. Deploy to Staging — Automatic deployment to non-prod
6. Integration/E2E Tests — Test in staging environment
7. Deploy to Production — Manual approval gate or automatic (if brave)
8. Verify — Smoke tests, synthetic monitoring, canary analysis
9. Rollback — Automatic rollback if verification fails

Deployment Strategies

Blue-Green:

• Two identical environments (blue = current, green = new)
• Switch traffic all-at-once after verification
• Instant rollback (switch back to blue)
• Cost: 2x infrastructure during deployment

Canary:

• Gradually shift traffic (1% → 5% → 25% → 100%)
• Monitor error rates and latency at each stage
• Automatic rollback if metrics degrade
• Best for: High-traffic services where gradual verification matters

Rolling Update:

• Replace instances one-by-one (or in batches)
• No extra infrastructure needed
• Slower rollback (must reverse the rolling process)
• Default for Kubernetes Deployments

Feature Flags:

• Deploy code but control activation separately
• Enable for specific users/regions before full rollout
• Decouple deployment from release
• Tools: LaunchDarkly, Unleash, custom implementation

Pipeline Interview Questions

Q: Design a CI/CD pipeline for a microservices architecture with 20 services.

A: Key considerations:

• Monorepo vs polyrepo (affects trigger strategy)
• Shared pipeline templates (DRY — don't repeat pipeline code)
• Service-specific deployment configurations
• Dependency-aware deployment ordering
• Parallel builds where possible
• Environment promotion (dev → staging → canary → prod)
• Rollback strategy per service (not just global)
• Observability: deploy markers in monitoring tools

Observability and Monitoring

The Three Pillars

Metrics (Prometheus/Datadog):

• RED method for services: Rate, Errors, Duration
• USE method for resources: Utilization, Saturation, Errors
• Business metrics: Revenue, sign-ups, user actions
• Alerting: Alert on SLO burn rate, not on individual metrics

Logs (ELK/Loki):

• Structured logging (JSON format with consistent fields)
• Log levels: ERROR (pages someone), WARN (investigate soon), INFO (audit trail), DEBUG (local only)
• Correlation IDs: trace a request across services
• Retention strategy: hot (7 days), warm (30 days), cold (1 year), archive

Traces (Jaeger/Tempo):

• Distributed tracing across service boundaries
• Span hierarchy: parent → child relationships
• Trace sampling (head-based vs tail-based)
• Use for: latency debugging, dependency mapping, bottleneck identification

SLOs, SLIs, and Error Budgets

SLI (Service Level Indicator): The metric you measure

• Example: Percentage of requests completing in < 200ms

SLO (Service Level Objective): The target value for the SLI

• Example: 99.9% of requests should complete in < 200ms (over a 30-day window)

SLA (Service Level Agreement): Business contract with consequences

• Example: If SLO is violated, customer gets service credits

Error Budget: 100% - SLO = acceptable error

• 99.9% SLO = 0.1% error budget = ~43 minutes of downtime per month
• When error budget is consumed: freeze deployments, focus on reliability
• When error budget is healthy: deploy freely, take risks

Alerting Best Practices

1. Alert on symptoms, not causes — Alert on "users can't log in," not "CPU is 80%"
2. Every alert must be actionable — If receiving the alert doesn't change your behavior, remove it
3. Severity levels: P1 (page immediately), P2 (respond in 1 hour), P3 (next business day)
4. Reduce noise: Group related alerts, use intelligent suppression during known outages
5. Document runbooks: Every alert links to a runbook explaining: what it means, how to investigate, how to resolve

Incident Management

The Incident Lifecycle

1. Detection — Monitoring alert, customer report, or automated check
2. Triage — Assess severity (P1-P4), assign incident commander
3. Communication — Status page update, stakeholder notification
4. Investigation — Follow the data (metrics → logs → traces)
5. Mitigation — Restore service (rollback, failover, hotfix)
6. Resolution — Root cause fix (permanent)
7. Postmortem — Blameless review, action items, learning

Troubleshooting Framework (For Interview Scenarios)

When given a troubleshooting scenario:

1. Assess impact: "First, I'd check: how many users are affected? Is it total or partial outage?"
2. Check recent changes: "Were there any deployments in the last hour? Config changes? Infrastructure changes?"
3. Follow the request path: Start from the user and trace through each component
4. Use metrics → logs → traces: Metrics show WHAT's wrong, logs show WHERE, traces show HOW
5. Isolate the component: "Is it the load balancer? The application? The database? The network?"
6. Mitigate first, debug later: "I'd rollback the recent deployment while continuing to investigate root cause"

Troubleshooting Scenarios (Common Interview Questions)

Scenario: API latency increased 5x after a deployment

• Check deployment diff (what changed?)
• Look at database query times (new N+1 query?)
• Check memory/CPU (resource saturation?)
• Check downstream service latency (dependency issue?)
• Check cache hit rate (cache invalidated by deployment?)

Scenario: Intermittent 503 errors for 5% of users

• Check pod health (some pods unhealthy?)
• Check node resources (one node overloaded?)
• Check network policies (connectivity issues?)
• Check load balancer algorithm (sticky sessions?)
• Check race conditions (connection pool exhaustion?)

Security (Increasingly Important in DevOps/SRE Interviews)

Key Topics

• Least privilege: IAM roles with minimal permissions, regular access reviews
• Network security: VPCs, security groups, private subnets for databases
• Secret management: Vault, AWS Secrets Manager, rotation policies
• Container security: Non-root containers, read-only filesystems, vulnerability scanning
• Supply chain security: Signed images, SBOM, dependency scanning, Sigstore
• Compliance: SOC2, HIPAA, GDPR implications for infrastructure

How to Practice for DevOps/SRE Interviews

1. Build real infrastructure — Deploy a multi-service app on Kubernetes with Terraform, CI/CD, and monitoring
2. Break things intentionally — Kill pods, saturate resources, inject network failures. Practice diagnosis.
3. Write incident postmortems — For real outages you've experienced or read about publicly
4. Practice design questions verbally — "Design a deployment pipeline for..." should be a 35-minute verbal exercise
5. Mock interviews — DevOps/SRE interviews are highly conversational. Practice explaining architectures and troubleshooting scenarios out loud.