Kubernetes Interview Questions

etcd uses Raft consensus requiring a strict majority quorum. 3 nodes tolerate 1 failure (quorum=2), 5 nodes tolerate 2 failures (quorum=3). 4 nodes also only tolerate 1 failure same as 3 -- the odd-count step-up is meaningful.

Already-running Pods continue running -- kubelets are autonomous. What stops: new scheduling, failure recovery, kubectl commands, rolling updates, and HPA decisions.

A continuous control loop that watches the API Server for objects, compares desired state to actual state, and takes actions to close any gap. This runs indefinitely, making Kubernetes self-healing.

etcd loses quorum; the control plane stops making decisions. Existing Pods continue running (kubelets are autonomous) but nothing new can be scheduled, crashed Pods cannot be replaced, and kubectl commands fail. Prevention: distribute control plane nodes across at least 3 AZs.

The API Server is down or network-partitioned from the client. The application continues normally because kubelets and the container runtime are autonomous. kubectl always requires a reachable API Server.

Filtering eliminates nodes that cannot run the Pod (insufficient resources, untolerated taints, failed affinity). Scoring ranks remaining feasible nodes. The highest-scoring node is selected and a Binding is written. The Scheduler never starts containers.

Container Runtime Interface -- a standardized gRPC API decoupling kubelet from any specific runtime. Lets Kubernetes support containerd, CRI-O without runtime-specific kubelet code. Enabled dockershim removal.

iptables (legacy, sequential rules, cost grows linearly), IPVS (hash-table kernel load balancer, scales better), eBPF (lowest per-packet overhead, used by CNIs like Cilium).

Complete absence of scheduling events means the Scheduler is not seeing the Pod -- check whether the Scheduler is healthy. A FailedScheduling event with a reason means the Scheduler works but no node satisfies constraints. Different root causes requiring different diagnoses.

With failurePolicy: Fail, an unreachable webhook causes rejection of every matching creation. Fix: ensure the webhook has HA and readiness gating before registration. Treat admission webhooks with the same operational rigor as control plane components.

Init containers run strictly sequentially in listed order; each must exit with code 0 before the next starts. All must complete before any app container or native sidecar starts.

In the older pattern, a sidecar was just a regular container with no ordering guarantees -- it could terminate before the app. The native sidecar (restartPolicy: Always on an init container) guarantees it starts before app containers and is signaled only after them.

Phase (Pending, Running, Succeeded, Failed, Unknown) is coarse. Conditions (PodScheduled, Initialized, ContainersReady, Ready) are granular booleans. Automation should check the Ready condition -- a Pod can be phase Running while Ready is still False.

Phase Running only means the container process started. 0/1 Ready means the readiness probe is failing. Check the readiness probe configuration and startup logs.

Check DNS resolution or network policies affecting newly scheduled Pods differently. Also verify the init container retry logic is not overly conservative with long fixed sleep intervals.

maxUnavailable caps how far below desired replica count the rollout can go. maxSurge caps how far above desired it can go temporarily. Both zero is invalid -- the rollout is impossible. Tuning them balances rollout speed vs capacity headroom.

Each revision is backed by a retained ReplicaSet at zero replicas. Rollback simply scales the target previous ReplicaSet back up and the current one down -- the Pod template already exists, making rollback much faster than a fresh deploy.

Walk through systematic diagnosis: check events, logs, and metrics. Cross-reference observability data. Form a hypothesis and test before applying a fix.

The PVC is NOT deleted. The replacement Pod for that ordinal reattaches to the same PVC, resuming with previous data intact.

A Deployment reconciles toward a fixed replica count. A DaemonSet reconciles toward one Pod per eligible node -- adding a node creates a DaemonSet Pod, removing a node removes it.

Check events with kubectl describe, examine logs, review metrics. Cross-reference Prometheus data. Form hypothesis and test before applying a fix.

Prevents a CronJob from starting a new Job if a previous run is still active -- new run is skipped.

A Job hanging indefinitely if its work blocks. It enforces a hard ceiling on total Job runtime, turning a hang into a bounded failure.

Check events with kubectl describe, examine logs, review metrics. Cross-reference Prometheus data. Form hypothesis and test before applying a fix.

They build in layers: ClusterIP provides base internal virtual IP. NodePort adds a port on every node. LoadBalancer adds a cloud-provisioned external LB pointing at the NodePort.

Objects tracking which Pod IPs currently back a given Service, kept current by a dedicated controller. kube-proxy watches these to program forwarding rules.

Check events with kubectl describe, examine logs, review metrics. Cross-reference Prometheus data. Form hypothesis and test before applying a fix.

By default every Pod can reach every other Pod with no restriction. NetworkPolicy objects are required to introduce any restriction.

For whichever direction the policy addresses, that Pod's traffic becomes default-deny except for explicit allows. Pods not selected remain fully open.

Check events with kubectl describe, examine logs, review metrics. Cross-reference Prometheus data. Form hypothesis and test before applying a fix.

One NODE at a time, not one Pod. Multiple Pods on the same node can mount and use an RWO volume simultaneously.

Delays dynamic provisioning until a Pod referencing the PVC is being scheduled, letting the Scheduler choose a zone-compatible node first.

Check events with kubectl describe, examine logs, review metrics. Cross-reference Prometheus data. Form hypothesis and test before applying a fix.

Utilization percentage is calculated relative to the Pod's requested resource value as a baseline denominator. Without a request, the percentage calculation has no basis.

Both react to the same signal (e.g., CPU) and can interact unpredictably in a feedback loop.

Check events with kubectl describe, examine logs, review metrics. Cross-reference Prometheus data. Form hypothesis and test before applying a fix.

NoSchedule prevents new untolerated Pods from being scheduled. PreferNoSchedule is the soft version. NoExecute evicts already-running Pods that don't tolerate it, optionally after tolerationSeconds.

Rules are only evaluated at scheduling time. Once a Pod is placed, subsequent changes to node labels or taints do not retroactively evict or move the running Pod. Only NoExecute taints have ongoing eviction effect.

Check events with kubectl describe, examine logs, review metrics. Cross-reference Prometheus data. Form hypothesis and test before applying a fix.

A subject's effective permissions are the union of every Role/ClusterRole bound to it. There is no deny rule type. Anything not explicitly granted is denied by omission.

RBAC governs access to the Kubernetes API. Security Context governs what a container is allowed to do at the OS/kernel level once running. Completely independent layers.

Check events with kubectl describe, examine logs, review metrics. Cross-reference Prometheus data. Form hypothesis and test before applying a fix.

Pre-computed PromQL expressions stored as new time-series, re-evaluated each cycle. Use them when a computation is expensive and queried frequently by dashboards or alerts.

Prometheus re-evaluates alerting rules every 15-30s so the same alert fires repeatedly. AlertManager collapses repeated firings to a configurable repeat_interval.

Check events with kubectl describe, examine logs, review metrics. Cross-reference Prometheus data. Form hypothesis and test before applying a fix.

Helm uses templating -- parameterized YAML rendered to final manifests. Kustomize uses explicit patches transforming plain YAML without any templating language.

Each revision is backed by a retained Secret. Rollback re-applies the stored manifest set from that revision, which is much faster than a fresh deployment.

Check events with kubectl describe, examine logs, review metrics. Cross-reference Prometheus data. Form hypothesis and test before applying a fix.

Traffic load-balances across all backing Pods regardless of version. 1 canary and 9 stable Pods gives approximately 10% canary -- not precise. Precise splitting requires an Ingress controller or service mesh with explicit traffic-weight rules.

Argo Rollouts queries external metric providers during a rollout and automatically rolls back if success conditions are not met. Native Kubernetes has no concept of metric-gated deployment.

Check events with kubectl describe, examine logs, review metrics. Cross-reference Prometheus data. Form hypothesis and test before applying a fix.

selfHeal causes ArgoCD to automatically revert manual kubectl changes that diverge from Git state. Git becomes absolutely authoritative -- direct kubectl edits to ArgoCD-managed resources are ephemeral and actively undone.

prune: true causes ArgoCD to delete Kubernetes resources that exist in the cluster but no longer appear in Git. Without it, removed resources persist indefinitely, diverging cluster from Git state.

Sync status reflects whether the cluster matches Git. Health status reflects whether deployed resources are functioning. A resource can be Synced (matches Git) but Degraded (Pods crashing), or OutOfSync (differs from Git) but Healthy (current state works). Both are independently meaningful.

GitHub Actions generates a short-lived JWT token per workflow run that cloud providers exchange for temporary credentials scoped to that run. No long-lived access keys are stored in secrets, eliminating persistent credentials that can be leaked or misused after the pipeline is decommissioned.

This is exactly correct selfHeal behavior. The right approach is committing the replica change to the GitOps config repo so ArgoCD sees it as the new desired state and applies it durably. Manual kubectl changes are not durable in a selfHeal-enabled GitOps setup.

If ArgoCD uses polling with a long interval, the delay is expected. If webhooks are configured, check webhook delivery history in GitHub -- delivery may have failed. Also check ArgoCD controller logs for errors processing the new Git state.

Istio injects an Envoy sidecar proxy into every Pod and configures iptables rules to intercept all traffic through the proxy. Applications communicate in plaintext on localhost; the proxy handles TLS termination, certificate presentation, and peer authentication transparently.

VirtualService defines routing rules -- how traffic for a destination is routed (weights, retries, fault injection, headers). DestinationRule defines the behavior for traffic once it has been routed to a specific service -- subsets (versions), load balancing policy, connection pool settings, and outlier detection (circuit breaking).

The monitoring agent is not in the mesh (no sidecar) so it sends plaintext traffic. STRICT mode rejects plaintext connections. Fix: enroll the monitoring namespace in the mesh, or create a PeerAuthentication exception for that specific port/workload, or switch to permissive mode for that namespace.

Check that DestinationRule with correct subset labels matches your Pod versions accurately. If subset selectors don't correctly identify which Pods are v1 vs v2, Envoy may not be routing as expected. Also verify the VirtualService is in the same namespace as the service or correctly references it.

The liveness probe runs throughout the Pod's lifetime to detect hangs and trigger restarts. The startup probe runs only during startup and gives the application time to initialize. Without a startup probe, the liveness probe's timeout applies from the first second, killing newly started Pods before they finish JVM warm-up, data loading, or connection pool establishment.

When Kubernetes sends SIGTERM, Spring Boot stops accepting new HTTP requests but continues processing in-flight requests until they complete or spring.lifecycle.timeout-per-shutdown-phase is reached. Kubernetes's terminationGracePeriodSeconds must be longer than the graceful shutdown timeout, otherwise SIGKILL arrives and cuts off in-flight requests.

JVM exceeded its heap limit. Check: (1) container memory limit -- is it actually set? (2) -XX:MaxRAMPercentage or -Xmx value -- is the heap ceiling correct? (3) Heap dump/metrics -- is there a leak or sustained high allocation? With MaxRAMPercentage, also check whether non-heap (metaspace, direct buffers) is consuming unexpected memory in addition to heap.

Check the relationship between terminationGracePeriodSeconds, the graceful shutdown timeout, and how quickly the load balancer removes the Pod from its backend pool. If the LB continues routing to a Pod that has already stopped accepting requests, 502s result. Also check readiness probe removal speed -- the EndpointSlice controller removes the Pod from Service endpoints after readiness fails, but there may be a propagation delay.

Cluster HA means the Kubernetes management layer (control plane) can survive failures. Application HA means your application can continue serving traffic despite node or Pod failures. Both require independent design: 3-AZ control plane gives cluster HA; topology-spread Deployments with multiple replicas and PodDisruptionBudgets give application HA.

A backup that has never been successfully restored is not a verified backup. Corruption, format incompatibilities between etcd versions, or incomplete backup procedures may prevent restoration in an actual disaster. Quarterly restore drills verify the entire backup-and-restore process works under the conditions you would face in a real incident.

With 3 control plane nodes and 1 lost, etcd still has a quorum of 2. The cluster continues operating normally -- scheduling, failure recovery, and kubectl commands all work. The remaining 2 control plane nodes handle all API requests. Worker nodes in the affected AZ are lost (nodes become NotReady), their Pods are evicted and rescheduled to healthy nodes in surviving AZs.

ResourceQuota enforcement is designed to prevent this from affecting other namespaces. The affected team needs to either clean up existing resources, request a quota increase, or optimize their resource requests/limits. Ops teams should monitor quota utilization as a leading indicator of capacity needs.

TIP: For detailed answers to all 100 questions, refer to the Interview Q&A sections in each chapter. The chapters are organized to match the question difficulty tiers above.

The Scheduler has not processed this Pod at all -- check Scheduler Pod health. If FailedScheduling events exist, read the reason: Insufficient cpu, Taints not tolerated, or affinity rules not satisfiable are the most common causes.

The 6th Pod is not passing readiness. Check kubectl logs on the new-version Pod and describe for events. The 5 existing ready Pods count against maxUnavailable so the rollout cannot remove one until the 6th is ready.

The Pod selector in the Service spec doesn't match the Pod labels, or all matching Pods are failing readiness. Use kubectl get endpointslices to verify, and check Pod conditions.

Check whether startingDeadlineSeconds is set -- if it is too short and the cluster was briefly unavailable, missed runs beyond the deadline are permanently skipped. Also check concurrencyPolicy: Forbid with a long-running previous run.

Data is present -- the new Pod is attached to the correct PVC (PVCs persist across Pod lifecycle). The issue is at the application or storage layer: check whether the PVC actually bound to the same underlying volume and whether the PV's data is intact.

Check whether ArgoCD is polling or using webhooks. If polling, the default 3-minute interval means 20 minutes of OutOfSync is unusual -- check controller logs. If webhooks configured, check GitHub webhook delivery history for the failed delivery.

DOWN means Prometheus cannot scrape /metrics. Check: (1) is the Pod running and healthy? (2) Is the service port correct in the ServiceMonitor? (3) Is there a NetworkPolicy blocking Prometheus? (4) Is the metrics endpoint actually exposed at the configured path?

Check kubectl describe node for Conditions (MemoryPressure, DiskPressure, PIDPressure). Check node-problem-detector logs if installed. SSH to node and check kubelet status. Check system dmesg for OOM kill or disk errors.

The cloud controller hasn't provisioned the LB. Check events on the Service. If on a bare-metal cluster, no cloud controller exists -- use MetalLB or NodePort instead. If on a cloud, check cloud-provider annotations and IAM permissions.

The image registry credentials are missing or expired. Check whether an imagePullSecret is configured on the ServiceAccount or Pod spec. Verify the Secret exists and the credentials are valid.

Check: (1) Is Metrics Server installed and running? (2) Does kubectl top pods show data? (3) Are resource requests set on the Pods (required for HPA percentage calculation)? (4) Is current replica count at maxReplicas?

Check the Ingress rules -- verify host, path, and pathType for Service B match exactly. Check whether Service B has healthy Endpoints. Check Ingress controller logs for routing decisions.

Check CA logs for 'unschedulable' reasons. CA only adds nodes if the Pods are unschedulable due to resource constraints. Pods blocked by taints/affinity that no node pool could satisfy won't trigger scale-out.

JVM heap exceeded container memory limit. Fix: (1) Increase container memory limit. (2) Add -XX:MaxRAMPercentage=75 so JVM respects the container limit. (3) Verify non-heap (metaspace, direct buffers) is not excessive.

Check API Server load (high QPS). Large CRD schemas with expensive validation webhooks can add latency. Also check etcd write latency. Consider using kubectl diff first to verify only changed resources are being applied.

Check the namespace label (istio-injection: enabled). Also check whether there is an annotation on the Pod spec disabling injection (sidecar.istio.io/inject: 'false'). New Pods pick up the setting but existing Pods need deletion and recreation.

The CNI plugin doesn't enforce NetworkPolicy (e.g., Flannel without policy support). Or the policy selector is incorrect. Test enforcement with a specific deny-all policy and verify traffic is actually blocked.

Check etcd certificate expiry (common cause of etcd-API Server communication failure). Check network connectivity between API Server and etcd endpoints. Check etcd disk usage -- a full disk causes etcd to stop processing writes.

A possible ConfigMap or Secret issue -- the application may cache config at startup. Check whether the relevant ConfigMap or Secret was updated. If volume-mounted, the file may have updated but the application hasn't reloaded. If env var, a rolling restart is needed.

The PDB's minAvailable constraint cannot be satisfied -- the number of ready replicas is already at or below the minimum. Either scale up the Deployment first, or temporarily adjust the PDB (with care) before draining.