DevOps Interview Questions That Look Simple — Until the Follow-Up Questions Begin

But the real challenge usually starts with the follow-up questions. Because in real-world DevOps and SRE environments, knowing a definition is only the starting point. The deeper questions are: What happens when something changes, fails, or behaves unexpectedly in production? A pod keeps restarting. An application suddenly becomes slow. A Kubernetes node reports an error. A deployment completes successfully — but users start seeing failures. These situations require more than knowing commands or memorizing definitions. They require a structured approach to troubleshooting, investigation, and root-cause analysis. Here are some DevOps questions that test that deeper understanding. 1. Terraform: count vs for_each The basic question is: What is the difference between count and for_each? The more important question is: What happens to your infrastructure when resources are removed, reordered, or their keys change? count uses numeric indexes, while for_each uses unique keys. That difference can have a significant impact on how Terraform tracks resources and plans changes. The real question is not just which one works. It is: Which one makes your infrastructure changes safer and more predictable? 2. Production Latency: Where Did the Extra 4 Seconds Go? Scenario: An application normally responds in 1 second. Suddenly, production latency increases to 5 seconds. What would you investigate? The problem could be anywhere: Application processing Database queries Connection pools Redis or cache performance Downstream services Network latency Kubernetes resource constraints A recent deployment The important part is not randomly checking everything. The goal is to trace the request and answer: Where exactly are those additional 4 seconds being spent? This is where metrics, logs, and distributed tracing become extremely valuable. 3. Kubernetes: CrashLoopBackOff Without Useful Logs A pod is continuously restarting. You check the logs — but they don't tell you much. What next? A good investigation might include: kubectl describe pod <pod-name> kubectl logs <pod-name> --previous Then investigate: Exit codes Events Health probes Environment variables Secrets and ConfigMaps Resource limits OOMKilled events The important lesson: The application logs are only one source of evidence. Kubernetes events and container termination details can often reveal what the application logs do not. 4. Prometheus Alert: NODE_0 ERROR You receive an alert: NODE_0 ERROR What is your first action? Restart the node? Not necessarily. First, you need to understand the impact: Is the node actually unhealthy? Are workloads affected? Is the issue CPU, memory, disk, or network-related? Are pods being evicted? Did a recent infrastructure change trigger the problem? A strong incident response process looks like: Alert → Validate → Investigate → Identify Root Cause → Remediate → Monitor The alert tells you that something may be wrong. Your job is to determine what is actually wrong. 5. Redis: What Happens When the Cache Fails? A simple question might be: What is Redis? A better production question is: What happens to your application if Redis suddenly becomes unavailable? The answer depends on how Redis is being used. If Redis is only a cache, the application might fall back to the database. If Redis stores sessions, rate limits, queues, or critical state, the impact could be much more serious. This leads to important design questions: Is the application resilient to Redis failure? Is there a fallback mechanism? What happens during a cache stampede? How is stale data handled? Knowing what a tool does is different from understanding its failure modes. 6. Deployment, StatefulSet, or DaemonSet? The basic question is: What is the difference between a Deployment, StatefulSet, and DaemonSet? The more useful question is: Why would you choose one for a particular workload? Deployment → interchangeable, stateless application replicas StatefulSet → stable identity and persistent storage DaemonSet → one pod per node or selected nodes The right answer depends on the behavior your workload requires.