I'm preparing for DevOps interviews and have about four years of experience, but only limited hands-on Kubernetes exposure. The documentation is extensive, so I'm trying to prioritize the skills that are genuinely expected at an intermediate level and commonly used with real workloads. In particular, I'm unsure whether I should spend much time learning how to tune control-plane components such as the scheduler and API server, or whether that is usually handled by platform or SRE teams.
I already understand Deployments, StatefulSets, taints and tolerations, ConfigMaps, Services, and node affinity. I've set up Minikube, deployed a basic three-tier application, and have been practicing hands-on labs. Which Kubernetes topics should I know thoroughly, which should I understand conceptually, and which advanced areas can I safely postpone?
4 Answers
Use a structured course or book as a checklist, but don’t feel obligated to master every advanced chapter before applying. A solid intermediate foundation includes workloads, scheduling basics, networking, storage, security, observability, upgrades, and common failure recovery. Be honest about what you have practiced and describe your projects clearly; interviewers can usually tell when someone is claiming production experience they don’t have.
It’s worth learning what the scheduler and API server do, but you probably don’t need to tune their internal configuration yet. Know how scheduling decisions are influenced by resource availability, affinity rules, taints, and tolerations, and understand the role of the API server, controller manager, scheduler, and backing data store. For most DevOps interviews, applying those concepts to deployment and troubleshooting questions is enough.
For an intermediate DevOps interview, prioritize the pieces you’ll regularly use and troubleshoot: Deployments and StatefulSets, Services and Ingress, ConfigMaps and Secrets, resource requests and limits, RBAC, persistent volumes and claims, rolling updates and rollbacks, horizontal autoscaling, and network policies.
You should understand the scheduler, control-plane components, and etcd at a conceptual level, including how node affinity, taints, and tolerations affect placement. Detailed tuning of the API server or scheduler is usually more relevant to platform engineering or dedicated SRE roles than to typical DevOps positions.
Spend extra time on troubleshooting scenarios: Pods stuck in Pending, CrashLoopBackOff, failed image pulls, Services that cannot reach Pods, incorrect probes, OOM kills, storage mounting failures, and deployments that fail to roll out. Those practical situations tend to be more valuable than memorizing every configuration option.
The best way to close the experience gap is to build and break things repeatedly. Expand your three-tier project with persistent storage, health checks, resource limits, autoscaling, an Ingress, restricted permissions, and some network policies. Then deliberately create failures and diagnose them with kubectl logs, describe, events, exec, and rollout commands.
A local cluster is useful for learning the fundamentals, and temporary Kubernetes playgrounds or labs can give you access to scenarios that are harder to reproduce locally. You won’t gain production experience instantly, but you can develop the same troubleshooting habits and explain what you would verify in a live environment.
That helps a lot. I’ll focus more on RBAC, networking, storage, and troubleshooting instead of getting stuck on control-plane tuning.