Interview Scenarios

What interviewers actually ask at senior/principal DevOps level. Not trivia — design questions, debugging scenarios, and trade-off discussions that test depth of understanding.

Design Questions

“Design a CI/CD pipeline for containerized microservices”

Expected answer structure:

Source → Build → Test → Scan → Push → Deploy → Verify

Key points to mention:

• Image tags: use git SHA (immutable), never :latest in production
• Build cache: mount cache layers for npm/pip to speed up builds
• Security gate: fail pipeline if HIGH/CRITICAL CVEs found
• Secrets: never in Dockerfile, use CI secrets manager + BuildKit secret mounts
• Multi-arch: build for amd64 + arm64 if targeting Graviton

“Design container orchestration for a stateful application (PostgreSQL)”

Expected answer:

StatefulSet + PVC (Retain policy) + Headless Service

Bonus points:

• Mention operators (CloudNativePG, Zalando Postgres Operator) for production databases
• Discuss when NOT to containerize databases (very high I/O, regulatory requirements)
• Mention that most teams use managed databases (RDS, Cloud SQL) and only containerize stateless services

Interview tip: If asked “should you run databases in containers?” — the answer is nuanced. For development and testing, always. For production, it depends on team expertise, I/O requirements, and operational maturity. Managed services (RDS) are simpler but more expensive. Operators (CloudNativePG) make it viable but require K8s expertise.

“Design a multi-tenant container platform”

Expected answer covers:

Key considerations to discuss:

• Namespace-level isolation is NOT as strong as separate clusters. Kernel is shared.
• For strict isolation (financial services, healthcare), consider separate clusters per tenant
• Cost allocation: use labels + Kubecost for per-tenant billing
• Noisy neighbor: ResourceQuotas prevent one tenant from consuming all resources

Debugging Scenarios

“A container keeps restarting. How do you debug it?”

Step-by-step approach:

# 1. Check the restart reason
kubectl describe pod <pod>
# Look for: OOMKilled, CrashLoopBackOff, Error, exit code

# 2. Check logs from the crashed container
kubectl logs <pod> --previous

# 3. Check events
kubectl get events --sort-by=.metadata.creationTimestamp | grep <pod>

# 4. Common causes by exit code:

Key insight: Exit code 137 is almost always OOM kill. Check kubectl describe pod for Reason: OOMKilled. Fix: increase memory limit or fix the memory leak. Don’t just increase the limit blindly — profile the app first.

“Pods can’t communicate across nodes”

Debugging checklist:

# 1. Can pods on the SAME node communicate?
kubectl exec pod-on-node-a -- curl pod-on-node-a-ip:port
# If yes → cross-node networking issue
# If no → CNI plugin broken on that node

# 2. Check CNI pods are running
kubectl get pods -n kube-system | grep -E 'calico|cilium|flannel|weave'
# Any CrashLoopBackOff? Restart them.

# 3. Check node firewall rules
# VXLAN (Flannel, Calico VXLAN): UDP 4789
# Calico BGP: TCP 179
# WireGuard (Calico, Cilium): UDP 51820

# 4. Check kube-proxy mode
kubectl get configmap kube-proxy -n kube-system -o yaml | grep mode
# iptables or IPVS — check respective rules on nodes

# 5. Check node-to-node connectivity
kubectl debug node/<node> -it --image=busybox -- ping <other-node-ip>

“DNS resolution is slow in the cluster”

Root cause is usually the ndots:5 default:

# Default /etc/resolv.conf in a K8s pod:
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

A lookup for api.example.com (4 dots including implicit trailing) triggers:

1. api.example.com.default.svc.cluster.local → NXDOMAIN
2. api.example.com.svc.cluster.local → NXDOMAIN
3. api.example.com.cluster.local → NXDOMAIN
4. api.example.com → SUCCESS

Four unnecessary DNS queries before the real one. At scale, this hammers CoreDNS.

Fixes:

# Option 1: Reduce ndots in pod spec
dnsConfig:
  options:
  - name: ndots
    value: "2"

# Option 2: Use FQDN with trailing dot (bypasses search domains)
# curl http://api.example.com.    ← trailing dot = absolute, no search

# Option 3: Scale CoreDNS
# kubectl scale deployment coredns -n kube-system --replicas=5

# Option 4: NodeLocal DNS Cache (DaemonSet that caches DNS on each node)

Trade-off Discussions

“Monolith in a container vs microservices?”

Principal-level answer: “Start with a monolith in a container. It gets you containerization benefits (reproducible builds, consistent environments, CI/CD) without microservice complexity. Extract services when you have a clear need: a component needs independent scaling, teams need independent deploy cycles, or a bounded context is well-defined. Most premature microservice decompositions create distributed monoliths that are worse than the original.”

“Managed Kubernetes vs self-managed?”

Principal-level answer: “Managed K8s for 95% of cases. The control plane management alone is worth the cost — HA etcd, API server upgrades, certificate rotation. Self-managed only when you need custom API server configuration (unusual admission controllers, specific authentication), air-gapped environments, or edge deployments where cloud isn’t available.”

“When NOT to use containers?”

• High-performance computing (HPC) where direct hardware access matters (GPU passthrough has overhead)
• Windows-native applications that don’t containerize well (COM, registry-dependent)
• Extremely latency-sensitive workloads where any kernel overhead matters (HFT)
• Embedded/IoT with very limited resources (though podman/containerd work on ARM)
• Regulatory environments where VM isolation is mandated by compliance

Rapid Fire Questions

Certification Exam Domains Reference

Docker Certified Associate (DCA)

Certified Kubernetes Administrator (CKA)

Certified Kubernetes Security Specialist (CKS)

Study Recommendations