Question 1
Difficulty: medium
Can you walk me through how you would design a production-ready Kubernetes cluster for a new application platform?
Sample answer
I would start by clarifying the workload patterns, security requirements, expected traffic, and operational maturity of the team. From there, I’d choose a cluster architecture that balances reliability and manageability, usually with separate environments for development, staging, and production. For production, I’d focus on multi-zone worker node pools, proper capacity planning, and clear separation between system and application workloads. I’d set up ingress, certificate management, external DNS, logging, monitoring, and secret handling early so teams are not forced to bolt them on later. I also pay close attention to RBAC, network policies, and image provenance to reduce risk. Finally, I’d make sure the platform has a strong deployment process, whether that is GitOps or well-controlled CI/CD, so changes are auditable and repeatable. My goal is always to build something that is secure, observable, and easy for engineers to use without sacrificing operational control.
Question 2
Difficulty: medium
How do you troubleshoot a pod that is stuck in CrashLoopBackOff?
Sample answer
I usually approach CrashLoopBackOff systematically instead of jumping to a fix. First, I check the pod events and container logs to see whether the application is failing during startup, missing a config value, or crashing because of a dependency issue. Then I inspect the deployment manifest for probes, resource limits, environment variables, mounted secrets, and command overrides. A very common root cause is an overly aggressive liveness probe that kills the container before it is ready, so I verify startup timing carefully. I also look at recent image changes, because a bad release or incompatible version can cause repeated restarts. If the logs are not enough, I’ll launch an interactive debug container or reproduce the issue in a similar environment. What matters is separating app problems from platform problems. In my experience, most CrashLoopBackOff issues are either configuration mistakes, missing dependencies, or startup timing problems, and a clear checklist saves a lot of time.
Question 3
Difficulty: hard
How would you secure a Kubernetes cluster for a regulated production environment?
Sample answer
In a regulated environment, I would treat security as layered and measurable. I’d start with identity and access control by enforcing least-privilege RBAC, using short-lived credentials, and separating duties between platform admins, developers, and auditors. Next, I’d secure the network with private cluster access where possible, strict network policies, and controlled ingress and egress paths. I’d also require signed or trusted images, vulnerability scanning in the CI pipeline, and admission controls to prevent risky workloads from being deployed. Secrets should be managed through an external secrets system or encrypted store rather than plain Kubernetes secrets alone. On the runtime side, I’d restrict privileged containers, host mounts, and root access unless there is a strong exception process. Just as important, I’d build a solid audit trail through logs, events, and policy reports so compliance is not an afterthought. I’ve found that security works best when it is automated, visible, and difficult to bypass accidentally.
Question 4
Difficulty: medium
Tell me about a time you improved the reliability or performance of a Kubernetes workload.
Sample answer
In one environment, a service was experiencing intermittent latency spikes during traffic peaks, but the symptoms were not obvious at first. I started by reviewing application metrics alongside node and pod resource usage, and I noticed the service was regularly hitting CPU throttling. The deployment had conservative resource requests but very low limits, which created unnecessary contention. I worked with the application team to adjust requests and remove an unrealistic CPU cap, then right-sized the HPA behavior so it reacted to real demand instead of waiting too long. I also checked whether the workload was spread evenly across nodes and found some imbalance, so I improved topology and pod distribution. After the changes, the latency spikes dropped significantly and the service became more predictable under load. The main lesson for me was that Kubernetes issues are often cross-functional: the app, the deployment spec, and the underlying capacity model all need to be aligned. I always try to validate improvements with metrics, not just intuition.
Question 5
Difficulty: easy
How do you decide between using a Deployment, StatefulSet, or DaemonSet?
Sample answer
I choose based on how the application behaves and what guarantees it needs. For most stateless web services or APIs, a Deployment is the right choice because it gives me rolling updates, scaling, and easy replacement of pods. If the workload needs stable network identities, persistent storage, or ordered startup and shutdown, then a StatefulSet is more appropriate. I usually think of databases, message brokers, and some distributed systems in that category. For node-level agents such as log collectors, security scanners, or monitoring components that should run on every node, I’d use a DaemonSet. I also consider operational details like upgrade behavior, storage dependency, and whether the application can tolerate pod rescheduling. I’ve seen teams pick a StatefulSet just because the app stores data, but that is not always enough; the control pattern has to match the actual runtime needs. My approach is to avoid overcomplicating the architecture and select the simplest controller that still preserves the application’s required behavior.
Question 6
Difficulty: medium
What is your approach to implementing CI/CD for Kubernetes deployments?
Sample answer
I prefer a deployment model that is repeatable, reviewed, and easy to roll back. Usually I start by separating build and deploy concerns. The pipeline should build the image, run tests, scan for vulnerabilities, and publish an immutable artifact. Deployment then becomes a controlled promotion step using manifests, Helm, Kustomize, or GitOps depending on the team’s maturity. I like GitOps for production because the cluster state matches versioned configuration, which makes audits and rollbacks much easier. I also make sure environment-specific values are handled cleanly so teams are not copying manifests by hand. A good pipeline should include validation before merge, such as schema checks and policy tests, so bad configurations do not reach the cluster. For riskier services, I’d add progressive delivery techniques like canary or blue-green rollouts. The key for me is reducing manual intervention without removing visibility. Teams move faster when deployment is boring, consistent, and recoverable.
Question 7
Difficulty: hard
Describe how you would handle a situation where a production deployment causes an outage.
Sample answer
My first priority would be to stabilize the service, not to preserve the failing release. I’d quickly assess whether the issue is isolated to one component, one namespace, or the whole cluster, and then decide whether to roll back, scale up, or disable the problematic path. If the deployment is clearly the cause, I would revert to the last known good version and confirm the service recovers before making further changes. I’d also communicate early with stakeholders so people know what is happening and what the impact is. Once the immediate issue is contained, I’d review logs, events, metrics, and recent config changes to identify the exact failure mode. In my experience, outages often come from small changes with unexpected side effects, like resource limits, probe timing, or config drift. I’d document the root cause, update any runbooks, and add a safeguard if possible, such as a canary gate or pre-deploy validation. I think a strong engineer is judged not just by how fast they fix an incident, but by how well they prevent the same issue from recurring.
Question 8
Difficulty: medium
How do you monitor Kubernetes workloads and know when something is wrong before users complain?
Sample answer
I focus on the full stack: cluster health, node health, workload behavior, and application experience. At the cluster level, I monitor node readiness, resource saturation, control plane availability, and any scheduling failures. For workloads, I track restarts, crash loops, pending pods, CPU and memory pressure, HPA behavior, and request latency. But I do not rely only on infrastructure metrics; I also want service-level indicators like error rate, response time, and throughput, because that tells me whether users are actually affected. Alerting should be actionable, not noisy, so I prefer thresholds tied to impact rather than every small fluctuation. I also look at trends over time to spot issues like gradual memory growth or capacity drift before they become incidents. Dashboards are useful, but alert tuning and ownership are just as important. A good monitoring strategy gives both engineers and support teams enough context to act quickly, and it reduces the chance that the first sign of a problem is a customer complaint.
Question 9
Difficulty: medium
How would you investigate a pod that cannot reach another service inside the cluster?
Sample answer
I would first confirm whether the failure is at the DNS, network, or application layer. I’d test service discovery by resolving the target service name from inside the failing pod or from a temporary debug pod in the same namespace. If DNS is fine, I’d verify the target service has endpoints and that the selector matches the backing pods. Next, I’d check whether network policies are blocking traffic between namespaces or labels, because that is a common reason for seemingly random connectivity issues. I’d also inspect the ports, target ports, and application listeners to make sure the service is actually exposing the correct port. If the cluster uses service meshes or ingress controllers, I’d review those configurations as well because they add another layer of routing behavior. I try to reproduce the issue with a simple curl or netcat test so I can isolate the failure. The main idea is to move from basic reachability to routing to policy to application behavior in a structured way, instead of guessing at the cause.
Question 10
Difficulty: easy
How do you keep your Kubernetes skills current and adapt to new tools or changes in the ecosystem?
Sample answer
I stay current by combining hands-on work with targeted learning. I follow release notes for Kubernetes and the tools we depend on, because changes in APIs, security defaults, and deprecations can have real operational impact. I also like to test new features in a non-production cluster before promoting them, since reading about a tool is never the same as using it under realistic conditions. When I learn something new, I try to connect it to a concrete problem I’ve already seen, such as rollout safety, policy enforcement, or resource efficiency. That makes the knowledge stick and helps me evaluate whether the tool is actually useful. I also learn a lot from incidents and postmortems, because they expose gaps that documentation does not always cover. If I’m introducing a new technology to a team, I focus on the operational cost, not just the features. For me, staying current is less about chasing every trend and more about understanding which changes improve reliability, security, or developer experience in a measurable way.
