Question 1

Describe a CI/CD pipeline you designed from scratch. How did you handle build speed bottlenecks and pipeline reliability?

Accepted Answer

Use STAR: (1) Situation - what was broken about the old system, (2) Task - what the new pipeline needed to achieve, (3) Action - specific technical decisions (cache layers, parallel jobs, artifact reuse), (4) Result - measured outcomes (% build time reduction, deploy success rate). A strong answer should cover: dependency caching strategy (e.g. pnpm store cache in GitHub Actions), parallel test execution, fail-fast logic, and handling flaky tests. Bonus if the candidate mentions integrated security scanning (SAST/SCA) in the pipeline.

Question 2

When a Kubernetes pod keeps going into CrashLoopBackOff in production, what is your debug process? Walk me through it step by step.

Accepted Answer

Present in triage order: (1) `kubectl describe pod` for Events and container state, (2) `kubectl logs --previous` for the prior crash logs, (3) Check resource limits (OOMKilled?), (4) Review liveness/readiness probe config, (5) Check recent image tag and config map/secret changes. Look for systematic thinking, not guesswork. Strong signals: knowing to use `kubectl events --sort-by=.lastTimestamp`, understanding the difference between OOMKilled and other exit codes, knowing how to use `kubectl exec` to debug a live container.

Question 3

Your company has 50 microservices on Kubernetes and the team is flying blind - no observability. How would you build a monitoring stack from scratch on a limited budget?

Accepted Answer

Present around the 3 pillars of observability (Metrics, Logs, Traces): (1) Metrics - Prometheus + Grafana (open-source), kube-state-metrics, node-exporter; (2) Logs - centralize with Loki (cheaper than ELK) or ELK depending on volume; (3) Traces - Jaeger or Tempo. Prioritize by impact: alerts first, dashboards second. Strong candidates will ask about log volume and budget before proposing a solution. Look for understanding of SLI/SLO (availability, latency, error rate) and how to set up practical alerting rules that avoid alert fatigue.

Question 4

Have you implemented GitOps with ArgoCD? Explain the difference between push-based and pull-based deployment, and why GitOps was (or was not) a good fit for your environment.

Accepted Answer

Clearly explain: Push-based - CI pipeline actively pushes changes to the cluster (e.g. kubectl apply after build); Pull-based - ArgoCD agent inside the cluster continuously polls the Git repo and syncs to desired state. Pull-based advantages: cluster doesn't need to expose its API externally, natural audit trail via Git history, self-healing. Top candidates will discuss secret management in GitOps (sealed secrets, external-secrets-operator) as this is a real pain point. Also probe about ApplicationSet for multi-cluster or multi-tenant deployments.

Question 5

Describe how you would perform a blue-green deployment for a stateful application (with a database) with zero downtime and no data loss.

Accepted Answer

Split into 2 parts: (1) Application layer - two parallel Blue/Green environments, load balancer switches traffic, health check before switching; (2) Database layer - the hard part: backward-compatible migrations, expand-contract pattern (add new column first so old app still works, delete old column after), read replicas to test Green before switching. This question filters DevOps engineers who truly understand stateful workloads. Look for mentions of: expand-contract migration pattern, feature flags for gradual rollout, and rollback plans when schema has already changed.

Question 6

Have you used Terraform or Pulumi to manage infrastructure? Tell me about a time the terraform state got corrupted or drifted and how you resolved it.

Accepted Answer

Structure: (1) Describe how drift was detected (terraform plan output, CloudWatch/monitoring alerts), (2) Root cause analysis - manual change outside Terraform? Race condition? (3) Fix approach: `terraform import` to reconcile, or `terraform state rm` + re-import, (4) Future prevention: remote state locking (S3 + DynamoDB), prohibiting manual changes, periodic drift detection. Good candidates will proactively mention state locking to prevent concurrent run conflicts. Bonus points for knowing Atlantis or Terraform Cloud for collaborative IaC workflows.

Question 7

Your team is suffering from alert fatigue - PagerDuty is ringing all night with low-priority alerts and engineers are starting to ignore them. How would you fix this?

Accepted Answer

4-step approach: (1) Audit - categorize alerts as actionable vs. noise over 2 weeks, (2) Triage - silence or downgrade alerts with no runbook, (3) Redesign - focus on symptom-based alerts (user impact) instead of cause-based alerts, (4) Process - establish monthly review cycle, SLO-based alerting, fair on-call rotation with secondary on-call. This is both a technical and leadership question. Look for candidates who understand alert fatigue is a cultural and technical problem. A strong answer mentions 'eliminate before you tune' - delete useless alerts before trying to adjust thresholds.

Question 8

Suppose you need to centralize logs from 30 servers into a single system for analysis. How would you design an ELK stack, and what scaling challenges would you tackle?

Accepted Answer

Architecture: (1) Beats/Fluentd agents on each server to collect logs, (2) Logstash or Kafka as buffer and transformer (critical during spikes), (3) Elasticsearch cluster with hot-warm-cold tiering to reduce cost, (4) Kibana for visualization and alerting. Discuss: index lifecycle management (ILM), shard sizing, and retention policy. Probe why Kafka is needed between Beats and Logstash (backpressure handling, replay capability). Strong candidates will suggest Loki over ELK if budget is constrained, since Loki does not index full log content.