Can you explain the core components of Kubernetes architecture and how they interact?

Start by describing the control plane and worker nodes, and explain the role of each main component such as kube-apiserver, etcd, kube-scheduler, kube-controller-manager, kubelet, and kube-proxy. Emphasize how the API server is the central point for state changes and how etcd stores cluster state. Give a simple flow example: you create a Deployment via kubectl, the API server records it, controllers reconcile desired state, scheduler places pods on nodes, and kubelet starts containers, reporting status back to the API server. When answering, mention practical signs of each component failing, such as API server errors in kubectl output, or kubelet failing to register nodes. Avoid overloading the interviewer with every subcomponent detail, focus on how these parts affect day-to-day operations and debugging steps you would take when a part is unhealthy.

What is the difference between a Deployment, StatefulSet, and DaemonSet and when would you use each?

Outline the purpose of each controller: Deployment manages stateless replicas with rolling updates, StatefulSet manages stateful applications that need stable network IDs and persistent storage, and DaemonSet runs a pod on every node or a subset for node-level services. Explain scheduling and lifecycle differences, especially how StatefulSet creates stable identities while Deployment does not. Give examples: use Deployment for a web frontend, StatefulSet for a database like Cassandra or an application needing persistent identity, and DaemonSet for log collectors or network agents. Mention gotchas like StatefulSet pods being terminated in order and how that impacts upgrades, and avoid using StatefulSet when you do not need stable storage or ordering guarantees.

How do you troubleshoot a pod in CrashLoopBackOff?

Describe a systematic approach: check pod events with kubectl describe pod, inspect container logs with kubectl logs, and if needed, run the container image locally or start a debug container to reproduce the issue. Explain looking for common causes such as misconfigured command or args, missing environment variables, failing startup probes, or permission issues. Provide an example: if logs show a database connection error, verify secrets and configmaps mounted correctly and check network policies or service endpoints. When troubleshooting, avoid restarting the pod repeatedly without understanding the root cause, and use kubectl exec or ephemeral debug containers to inspect runtime state.

Explain Kubernetes networking concepts and how Services, Ingress, and CNI plugins work together.

Start with the cluster network model where every pod has a routable IP and Services provide stable endpoints and load balancing over pods. Describe Service types like ClusterIP, NodePort, and LoadBalancer, and explain that Ingress manages HTTP routing at layer 7, usually through an Ingress controller, while CNI plugins implement the pod networking layer. Give a practical scenario: use a ClusterIP Service for internal microservices, an Ingress to expose HTTP with TLS termination, and a CNI like Calico or Flannel to provide pod-to-pod connectivity with policies. Mention common pitfalls such as misconfigured NetworkPolicies blocking traffic, or expecting a LoadBalancer type to work in environments without cloud provider integration.

What is etcd and how do you design it for high availability and backups?

Explain that etcd is the distributed key-value store that holds the cluster state and that it must be highly available and consistent for the control plane to work reliably. Discuss best practices like running an odd number of members across separate failure domains, using strong TLS authentication, and separating etcd from other workloads where possible. Give concrete backup and recovery steps: take regular snapshots using etcdctl snapshot save, store snapshots off-cluster, test restores in a staging environment, and monitor member health with etcdctl endpoint health. Highlight pitfalls such as restoring snapshots created from a different cluster topology without adjusting member configuration, and avoid running etcd on nodes that may be drained frequently.

How do PersistentVolumes, PersistentVolumeClaims, and StorageClasses work in Kubernetes?

Define PersistentVolume as the cluster resource representing physical storage, PersistentVolumeClaim as the request from a pod for storage, and StorageClass as a template that defines provisioner parameters for dynamic provisioning. Explain the binding process where claims are matched to available volumes or dynamically provisioned based on StorageClass. Provide an example: create a StorageClass that provisions SSD-backed volumes with reclaim policy Retain, then create a PVC and attach it to a StatefulSet so each replica gets its own volume. Mention common pitfalls like mismatched access modes or expecting ReadWriteMany where the underlying storage does not support it, and test your storage behavior in a non-production cluster.

When would you choose Helm over Kustomize, or vice versa, for managing Kubernetes manifests?

Compare the two tools by use case: Helm is a packaging tool with templating and parameterization that is useful for reusable charts and sharing third-party apps, while Kustomize focuses on patching and composing plain YAML without templating, which fits GitOps workflows. Explain that Helm excels when you need packaged dependencies and chart lifecycle features, while Kustomize is simpler for layering environment-specific overlays. Give an example: use Helm to install a third-party service like Prometheus because you can pull a maintained chart and set values, use Kustomize when you have an internal base manifest and you want a small set of overlays per environment. Warn against over-templating manifests in Helm which can hide actual YAML, and avoid forcing Helm when deterministic YAML patches are preferred for review processes.

How do resource requests and limits affect pod scheduling and Quality of Service?

Explain that requests inform the scheduler about the minimum resources a pod needs to be scheduled, while limits cap the resources a container can use at runtime; together they influence QoS classes like Guaranteed, Burstable, and BestEffort. Describe how Guaranteed QoS requires requests and limits to be equal, which prevents eviction under memory pressure, while BestEffort pods have no requests or limits and are most likely to be evicted. Provide a practical tip: set requests to the typical steady-state usage and limits to a slightly higher value to prevent noisy neighbors, and monitor with metrics to refine those numbers over time. Avoid setting limits too low which can cause OOM kills, and do not leave requests unset in production clusters since that can cause unpredictable scheduling.

Describe readiness and liveness probes and how they affect deployments and rolling updates.

Define liveness probes as checks that determine whether to restart a container that is unresponsive or deadlocked, and readiness probes as checks that determine whether a pod should receive traffic. Explain that Kubernetes will not route traffic to pods failing readiness checks, and that failing liveness probes trigger container restarts which can impact stability during startup. Give a concrete example: configure a readiness probe for an application that requires a warm-up step so it does not receive traffic until fully initialized, and keep liveness probes conservative during startup to avoid false restarts. Mention common mistakes such as using aggressive probe timeouts that cause flapping, and test probe settings under realistic load before rolling to production.

How do you secure a Kubernetes cluster using RBAC, network policies, and image security?

Cover the basics: use RBAC to grant least privilege by creating fine-grained Roles and RoleBindings, and avoid using cluster-admin unless necessary. Discuss network policies to restrict pod-to-pod communication with a whitelist approach, and image security practices such as scanning images for vulnerabilities, signing images, and using admission controllers to enforce policies. Offer a practical workflow: start by auditing current permissions with kubectl auth can-i and reduce broad permissions, apply NetworkPolicies for sensitive namespaces, and integrate an image scanning pipeline into CI to block known vulnerabilities. Warn against relying on namespace isolation alone for security, and ensure you have logging and monitoring in place to detect suspicious activity.

Tell me about a time you had to diagnose a production outage in a Kubernetes cluster. Walk me through what you did.

Situation: During a peak period our e-commerce cluster experienced increased 5xx errors and latency across multiple services, which caused customer impact and pager alerts. Task: As the on-call Kubernetes engineer, you needed to find the root cause quickly and restore service while communicating status to stakeholders. Action: You started by checking cluster-wide metrics and control plane logs, then narrowed the problem to a recent node upgrade that left several kube-proxy instances in a failed state, causing service endpoints to be inconsistent. You cordoned the unhealthy nodes, cordoned workloads to healthy nodes, rolled back the upgrade on the control plane, and redeployed kube-proxy with correct configuration while keeping stakeholders informed. Result: Traffic normalized within an hour, error rates dropped to baseline, and you created a postmortem documenting the upgrade checklist and an automated health check to catch kube-proxy failures earlier, reducing similar incidents in future by improving detection and rollback procedures.

Describe a time when you improved deployment reliability for a team using Kubernetes.

Situation: The team faced frequent deployment failures and service downtime during releases, which eroded confidence and slowed feature delivery. Task: Your goal was to reduce failed deployments and make rollouts safer while keeping the delivery pipeline fast. Action: You introduced Canary deployments for high-risk services, added readiness checks to prevent traffic to unhealthy pods, and automated rollback logic in the pipeline based on error-rate thresholds and latency. You also ran training sessions to align developers on proper probe settings and resource requests to prevent flapping under load. Result: Deployment-related incidents dropped significantly, rollout success rate improved, and mean time to recovery shortened because rollbacks were automated and clearer guardrails reduced risky configuration changes.

Give an example of a time you had to influence engineering teams about a platform change they resisted.

Situation: Developers resisted migrating stateful workloads to a managed storage class due to fear of vendor lock-in and migration effort, while platform goals required standardized storage for backups and compliance. Task: You needed to build consensus and create a migration path that minimized disruption and addressed their concerns. Action: You ran a short pilot with one noncritical service, documented performance and restore tests, and shared concrete rollback plans and metrics from the pilot. You also proposed incremental migration windows and provided automation scripts for data migration and validation so teams could opt in with low overhead. Result: After the pilot showed reliable backups and acceptable performance, several teams agreed to a phased migration, which improved backup reliability and reduced manual restore time while maintaining the ability to revert if issues arose.

Write a Kubernetes manifest for a Deployment running nginx with a readiness and liveness probe.

Explain the key fields first: the Deployment spec controls replicas and pod template, containers define image and probes, and probes use httpGet or exec commands to check health. Provide a short example manifest snippet and explain each probe parameter. Example snippet: apiVersion: apps/v1 kind: Deployment metadata: name: nginx-example spec: replicas: 3 template: spec: containers: - name: nginx image: nginx:1.21 ports: - containerPort: 80 livenessProbe: httpGet: path: /healthz port: 80 initialDelaySeconds: 30 periodSeconds: 10 readinessProbe: httpGet: path: / ready port: 80 initialDelaySeconds: 5 periodSeconds: 5. Common pitfalls include setting initialDelaySeconds too low causing false restarts and not aligning probe paths with actual application endpoints, so always test probes in a staging environment.

How do you set up Horizontal Pod Autoscaler (HPA) and what metrics can it use?

Describe HPA as a controller that scales the number of pod replicas based on observed metrics like CPU, memory via custom metrics API, or external metrics from tools such as Prometheus Adapter. Explain the basic kubectl autoscale command for simple CPU-based scaling and the manifest form for custom metrics. Give a quick manifest example: apiVersion: autoscaling/v2beta2 kind: HorizontalPodAutoscaler spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: my-app minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 60. Mention pitfalls such as not having metrics-server or custom metrics adapter installed, setting minReplicas too low for bursty traffic, and not tuning target utilization to your application's consumption profile.

Show how to port-forward a pod and when that is useful.

Explain that kubectl port-forward creates a local tunnel to a pod or service which is handy for debugging services that are not externally exposed, without changing cluster networking. Provide the basic command syntax and a common use case. Example command: kubectl port-forward pod/my-pod 8080:80 and explain that this forwards local port 8080 to port 80 on the pod, enabling you to curl localhost:8080 to test the service. Note limitations such as the tunnel being tied to your client session and not suitable for production traffic, and avoid leaving long-running port-forwards open on insecure networks.

How would you restore a failed etcd cluster from a snapshot?

Outline the high-level steps: secure a recent snapshot, boot a new etcd cluster or single node in restore mode using etcdctl snapshot restore, verify member URLs and TLS configuration, and start control plane components pointing to the restored data. Stress that you should restore to a maintenance window and ensure backups are consistent with application data if necessary. Mention practical checks: validate snapshot integrity before restore, update client and peer URLs if topology changed, and test the restore process in a staging environment so you are familiar with the commands and timing. Avoid restoring snapshots without cleaning up stale member configs or blindly reusing old member certificates that may not match the new cluster.

Provide an example of a NetworkPolicy that allows traffic only from a specific namespace.

Explain that NetworkPolicy is namespaced and controls ingress and egress for selected pods by label, and that policies are implemented by the CNI plugin when it supports network policies. Show a concise example and explain selectors used for pods and namespace. Example snippet: apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-namespace spec: podSelector: matchLabels: role: db ingress: - from: - namespaceSelector: matchLabels: team: frontend. This policy allows pods labeled role=db to accept traffic only from pods in namespaces labeled team=frontend. Warn that default deny behavior depends on whether any NetworkPolicy exists, and test policies carefully because a single overly restrictive rule can block critical communications.

kubernetes engineer Interview Questions: Complete Guide

Expect a mix of architecture, debugging, and hands-on questions in kubernetes engineer interview questions, often across a phone screen, a technical deep dive, and a live debugging or take-home task. You should be ready to explain core concepts, walk through manifests or kubectl commands, and show how you diagnose problems under pressure.

Common Interview Questions

Behavioral Questions (STAR Method)

STAR Method: Structure your answers using Situation, Task, Action, and Result to tell compelling stories about your experience.

Technical Questions

Questions to Ask the Interviewer

Show your interest by asking thoughtful questions

•What does success look like in this role after the first six months, and what are the main metrics I would own?
•Can you describe the current cluster topology, CI/CD process, and any pain points the team is actively working on?
•How does the team handle incident response and postmortems, and what role would I play during on-call rotations?
•What constraints or policies are in place around cluster upgrades, third-party operators, and storage choices?
•How does the team measure reliability and performance for platform services, and which observability tools do you use?

Interview Preparation Tips

1
Practice live debugging on a small cluster so you can demonstrate kubectl, logs, exec, and port-forward confidently under time pressure.
2
Prepare two or three concise stories around incidents, migrations, or automation projects using the STAR format and include measurable outcomes.
3
Be ready to read and explain a short manifest in an interview, highlighting why certain fields exist and what would break if changed.
4
Ask clarifying questions during system design and troubleshooting prompts, and narrate your thought process so interviewers can follow your approach.

kubernetes engineer Interview Questions: Complete Guide

Michael Rodriguez

Common Interview Questions

Behavioral Questions (STAR Method)

Technical Questions

Questions to Ask the Interviewer

Interview Preparation Tips

Related guides

kubernetes Interview Questions: Complete Guide

aerospace engineer Interview Questions: Complete Guide

agricultural engineer Interview Questions: Complete Guide

ai engineer Interview Questions: Complete Guide

kubernetes engineer Interview Questions: Complete Guide

Michael Rodriguez

Common Interview Questions

Q1Can you explain the core components of Kubernetes architecture and how they interact?

Q2What is the difference between a Deployment, StatefulSet, and DaemonSet and when would you use each?

Q3How do you troubleshoot a pod in CrashLoopBackOff?

Q4Explain Kubernetes networking concepts and how Services, Ingress, and CNI plugins work together.

Q5What is etcd and how do you design it for high availability and backups?

Q6How do PersistentVolumes, PersistentVolumeClaims, and StorageClasses work in Kubernetes?

Q7When would you choose Helm over Kustomize, or vice versa, for managing Kubernetes manifests?

Q8How do resource requests and limits affect pod scheduling and Quality of Service?

Q9Describe readiness and liveness probes and how they affect deployments and rolling updates.

Q10How do you secure a Kubernetes cluster using RBAC, network policies, and image security?

Behavioral Questions (STAR Method)

B1Tell me about a time you had to diagnose a production outage in a Kubernetes cluster. Walk me through what you did.

B2Describe a time when you improved deployment reliability for a team using Kubernetes.

B3Give an example of a time you had to influence engineering teams about a platform change they resisted.

Technical Questions

T1Write a Kubernetes manifest for a Deployment running nginx with a readiness and liveness probe.

T2How do you set up Horizontal Pod Autoscaler (HPA) and what metrics can it use?

T3Show how to port-forward a pod and when that is useful.

T4How would you restore a failed etcd cluster from a snapshot?

T5Provide an example of a NetworkPolicy that allows traffic only from a specific namespace.

Questions to Ask the Interviewer

Interview Preparation Tips

Related guides

kubernetes Interview Questions: Complete Guide

aerospace engineer Interview Questions: Complete Guide

agricultural engineer Interview Questions: Complete Guide

ai engineer Interview Questions: Complete Guide